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PREFACE 


The  McDonnell  Douglas  Astronautics  Company  has  been  engaged  In  a Space 
Station  Data  System  Analysis/Architecture  Study  for  the  National  Aeronautics 
and  Space  Administration,  Goddard  Space  Flight  Center.  This  study,  which 
emphasized  a system  engineering  design  for  a complete,  end-to-end  data  system, 
was  divided  Into  six  tasks: 


Task 

1. 

Functional  Requirements  Definition 

Task 

2. 

Options  Development 

Task 

3. 

Trade  Studies 

Task 

4. 

System  Definitions 

Task 

5. 

Program  Plan 

Task 

6. 

Study  Maintenance 

McDonnell  Douglas  was  assisted  by  the  Ford  Aerospace  and  Communications 
Corporation,  IBM  Federal  Systems  Division  and  RCA  In  these  Tasks.  The  Task 
Inter-relationship  and  documentation  flow  are  shown  In  Figure  1. 

This  report  was  prepared  for  the  National  Aeronautics  and  Space 
Administration  Goddard  Space  Flight  Center  under  Contract  No.  NAS5-28082 


Questions  regarding  this  report  should  be  directed  to: 

Glen  P.  Love 
Study  Manager 

McDonnell  Douglas  Astronautics  Company 
Huntington  Beach,  CA  92647 
(714)  896-2292 
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SSDS  SYSTEM  DEFINITION  REPORT 

1 . 0 INTRODUCTION 

The  McDonnell  Douglas  Astronautics  Company  has  been  engaged  in  a Space  Station 
Data  System  Analysis/Architecture  Study  for  the  National  Aeronautics  and  Space 
Administration,  Goddard  Space  Flight  Center.  This  study,  which  emphasizes  a 
system  engineering  design  for  a complete,  end-to-end  system,  is  divided  into 
six  tasks: 

Task  1.  Functional  Requirements  Definition 

Task  2.  Options  Development 

Task  3.  Trade  Studies 

Task  4.  System  Definition 

Task  5.  Program  Plan 

Task  6.  Study  Maintenance 

An  update  to  the  Task  1 report  along  with  the  revised  appendix  and  the 
preliminary  reports  on  tasks  2,  3 and  4,  were  submitted  to  NASA  on  1 May 
1985.  A 3 a result  of  the  Review  Item  Descriptions  (RIDs)  from  the 
NASA/Industry  review  of  these  reports,  the  SSDS  Workshop  Presentation  and  the 
continuing  study  efforts  at  MDAC,  certain  sections  of  Task  1 Appendix,  Task  3 
and  Task  4 Reports  have  been  updated  and  supplemented  with  additional  data. 

In  addition,  several  new  trade  studies  (Task  3)  have  been  completed.  The 
updates  and  the  newly  completed  trade  studies  form  the  package  for  this  final 
submittal . 

This  volume  contains  updates  to  the  Task  4 (System  Definition)  Report.  The 
key  task  1 products  that  form  the  basis  for  this  definition  report  are 
summarized  in  Figure  (1-1).  A summary  of  documentation  availability  is 
summarized  in  Figure  (1-2). 

McDonnell  Douglas  was  assisted  in  Task  1 by  the  Ford  Aerospace  and 
Communications  Corporation,  IBM  Federal  System  Division  and  RCA. 
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Non-SSIS  Elements 
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• SSIS  to  SSDS  Interfaces 

• Customer 

• Operator 

• Payloads 

• Subsystems  Sensors/ 
Effectors 

• Institutional  Services, 
Facilities  and  Functions 


SSDS  Functional  Requirements 

• Function  List 
(Hierarchlal  and  Data  Flow 
Diagrams) 

• Function  Data  Sheets 

• Customer  Requirements 
(Standard  Services) 

• Supporting  Analysis 

Key  Performance  Requirements 
Traceability  Matrices 


• End-To-End  SSIS  Concept 

• Functional  Topology 

• Functional  Architecture 

• Operating  Concept 

• Operator  Perspective 

• Customer  Perspective 


Figure  1-1.  Summary  of  Key  Task  1 Products 


This  report  has  been  prepared  for  the  National  Aeronautics  and  Space 
Administration  Goddard  Space  Flight  Center  under  Contract  No.  NAS5-28082  as 
part  of  Task  1 activities. 

Questions  regarding  this  report  should  be  directed  to: 

Glen  P.  Love 
Study  Manager 

McDonnell  Douglas  Astronautics  Company 
Huntington  Beach,  CA  92647 
(714)  896-2292 
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Figure  1-2.  Task  Documentation 


2.0  SYSTEM  DEFINITION  APPROACH/METHODOLOGY 

2 . 1 Objectives 

System  definition  is  the  process  of  analyzing  functional/performance 
requirements  and  deriving  balanced  architectural  design  concepts  that  can  be 
evaluated  in  terms  of  their: 

a.  Ability  to  meet  requirements , 

b.  Performance  and  growth  potential, 

c.  Technical  feasibility  and  risk,  and 

d.  Cost-effectiveness. 

This  requires  a systematic  decomposition  and  refinement  of  design-to 
requirements  such  that  a system  design  can  be  synthesized  from  the  technology 
available  in  the  appropriate  time  frame.  This  report  is  the  primary  product 
of  this  system  definition  process  and  describes  the  architectural  framework  to 
support  the  following  objectives: 

a.  Identification  of  critical  long-lead  SSDS  items. 

b.  Recommendations  for  technology  development  to  enhance  performance 
and/or  cost-effectiveness. 

c.  Cost  estimation. 

d.  Establish  technical  feasibility  within  performance  envelopes  and 
physical/environmental  constraints . 

e.  Quantify  those  architecture  design  attributes  that  will  support 
requirements  iteration/ref inement  leading  to  a cost-effective  balance 
between  requirements  and  design. 


2-1 


2.2  Relationship  To  Other  Tasks 


System  definition  (Task  4)  is  the  natural  extension  of  requirment  definition 
(Task  1)  where  design-to  requirements  and  characteristics  are  derived  from  a 
baseline  set  of  functional  and  performance  requirements . This  is  a step-wise 
procedure  that  progressively  leads  to  increased  levels  of  design  detail  within 
the  context  of  an  evolving  architecture . The  baseline  requirements  data  base 
developed  by  Task  1 is  the  primary  input  to  this  process  and  is  the  foundation 
on  which  architectural  concepts  are  established.  However,  it  is  recognized 
that  this  is  an  iterative  process  where  design  attributes  serve  to  measure  the 
feasibility  and  cost-effectiveness  of  the  requirements  baseline.  One  of  the 
key  functions  of  system  definition  will  be  to  clearly  identify  and  examine 
those  requirements  that  are  significant  cost  or  schedule  drivers.  The  intent 
is  to  strive  towards  an  implementable,  cost-effective,  acceptable  risk  design 
based  on  a balanced  set  of  requirements . 

As  shown  in  figure  2.2-1,  system  definition  is  directly  supported  by  options 
development  (Task  2)  and  trade  studies  (Task  3).  This  is  a highly  integrated 
relationship  with  the  system  definition  task  providing  the  basic  framework  and 
identifying  architectural  needs  that  focus  task  2/3  activities.  Options 
development  provides  the  information  base  for  technology,  design  and 
programmatic  alternatives  that  are  required  to  support  key  design/programmatic 
decisions  and/or  trade  studies.  Based  on  evolving  architectural  needs  and 
requirements , the  options  development  task  is  a coarse  filter  that  reduces  all 
possible  alternatives  to  a focused  subset  most  likely  to  contribute  to  system 
definition.  The  selection  of  preferred  options  is  accomplished  within  the 
system  definition  process  either  directly  or  via  trade  studies.  Those  design 
decisions  that  have  significant  architectural  or  cost  implications  and/or 
require  detailed  analysis  and  evaluation  are  subjected  to  trade  studies  within 
Task  3.  Trade  studies  are  performed  within  the  context  of  system  definition 
and  provide  a highly  visible  and  systematic  means  of  selecting  preferred 
design/technology  options.  A further  description  of  task  2 and  3 
methodologies  is  included  in  their  respective  task  reports. 
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Requirements  Definition 
(Task  1 Products) 
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System 

Definition 
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(Task  4) 

— Analysis 

— Partitioning/ 

Allocation 
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— Synthesis 

— Evaluation 

Architectural 
Needs 


Options 
Development 
(Task  2) 


/Focused 

'Data  Base  for  Key  1 / Subset  of 
Design  Decisions  Options 

Trade 
Studies 
(Task  3) 
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Selected  Options  and 
Supporting  Data 


System  Definition  Products 
— Architecture  Definition 
— Define  Critical  Long-Lead  SSDS 
Elements 

— Refined  Set  of  Requirements 
Figure  2.2-1.  Supporting  System  Analysis  Overview 


Focusing  Criteria 

■ Response  to  Requirements 

■ Key  Design/Cost  Driver 


Tradeoff  Criteria 

■ Performance 

■ Cost 

■ Growth 

■ Standardization 

■ Physical  Environmental 

■ RAM 


2.3  Task  Approach 

The  system  definition  task  approach  is  illustrated  in  figure  2.3-1  and  can  be 
characterized  as  systematic  and  incremental  in  nature.  This  process  is  a 
controlled  step-wise  refinement  with  verification  of  viability  before 
proceeding  to  the  next  step  of  design  detail.  Each  step  is  defined  as  the  (1) 
analyses/trades,  (2)  partitioning/  allocation,  (3)  design  synthesis,  and  (4) 
design  evaluation  necessary  to  provide  a stable  framework  for  more  detailed 
system  definition.  The  products  of  each  step  include  topology  refinement, 
functional  allocation,  nodal  characterization,  and  interconnection 
characteristics . The  specific  steps  represent  a systematic 
decomposition/ref inement  of  requirements  and  characteristics  and  are  defined 
as  follows: 

a.  Space/Ground  Allocation 

b.  Network  Architecture 

c.  Local  Area/Node  Architecture 
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Requirements 


Space/ 

Ground 

Allocation 


Level  of 
Distribution 
and  Design 
Detail 


Allocation  to  Space/Ground 
Link  Characteristics 


Network  Topology 

■ Allocation  to 
Network  Nodes 

Interconnection 
Characteristics 


Local 

Area  (Node) 
Architectures 


Allocation  to 
Computational/ 
Storage  Resources 


Key  Trade  Studies 

■ Automation 

■ Autonomy 


■ End-to-End  Networking 

■ Standardization 

■ Distributed  DBMS 

■ Space  Communications 


■ Local  Area  Networks 

■ BIU 

■ Network  Media 

■ Fault  Tolerance 


Figure  2.3*1.  Incremental  Design  Approach 


While  design  processes  are  generally  iterative  in  nature,  this  approach 
attempts  to  constrain  such  iteration  to  successive  steps  thus  allowing 
traceability  of  design  and  driving  requirements . 


The  first  step  is  the  space/ground  segment  allocation  that  is  supported  by 
three  major  trade  studies;  (1|)  space  autonomy,  (2)  function  automation,  and 
(3)  AI  automation.  Functions  were  allocated  to  space/ground  segments  based  on 
an  assessment  of  autonomy/  automation  goals,  cost,  risk,  and  performance 
benefits.  The  function  automation  study  identified  the  degree  to  which  a 
function  should  be  automated  and  the  AI  automation  study  considered  the 
applicability  of  AI  technology  vs.  conventional  techniques.  The  product  of 
this  step  is  a preliminary  space/ground  allocation  and  the  characterization  of 
functions  to  be  automated  (either  conventional  or  AI).  These  results  will  be 
re-examined  to  incorporate  Advanced  Technology  Advisory  Committee  (ATAC) 
recommendations . 


1 he  second  step  is  the  definition  of  an  SSDS  Network  architecture  and  is 
supported  by  a number  of  key  trade  studies.  This  step  includes  the  definition 
of  system  network  topology,  the  allocation  of  functions  to  network  elements, 
and  the  characterization  of  elements  and  their  interconnecting  communication 
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links.  While  the  allocation  of  functions  to  logical  elements  and  their 
assignment  to  physical  locations  is  relatively  straightforward  for  space 
elements,  a wider  range  of  alternatives  is  possible  for  ground  elements.  The 
system  network  topology  trade  study  evaluated  these  alternatives  and  developed 
a "reference  configuration"  that  is  described  in  section  3.  This  study 
considered  the  technical/cost  implications  of  communication  data  rates,  data 
buffering,  and  ease  of  customer  use.  Alternatives  were  evaluated  using 
simulation  and  modeling  tools.  This  definition  process  resulted  in  some 
iteration  with  the  space/  ground  allocation  step  to  reflect  the  additional 

insight  gained  from  this  level  of  end-to-end  definition. 

/ 

The  third  and  final  step  is  the  definition  and  characterization  of  the 
localized  architecture  of  each  element  defined  by  the  network  architecture . 
This  is  based  on  well  defined  interfaces  between  an  element  and  other  SSDS 
elements  or  SSDS  external  elements.  These  architectures  are  described  for 
space  elements  in  section  6 and  ground  elements  in  section  7.  The  level  of 
definition  provided  varies  greatly  depending  on  the  criticality  and  perceived 
cost  implications.  For  example,  the  architecture  of  space  elements  will 
require  significantly  more  design  definition  than  some  of  the  ground 
elements.  Ground  systems  can  use  more  commercial  hardware  and  software 
products  while  onboard  systems  will  tend  to  be  more  "customized"  and  will  have 
to  deal  with  additional  requirements  and  physical  constraints  imposed  by  the 
environment. 

The  following  sections  describe  the  key  activities  performed  during  system 
definition . 

2.3.1  Requirements  Analyses 

Requirements  analyses  are  related  activities  that  support  the  estimation  of 
processing,  storage  and  communication  resource  requirements  within  the  context 

of  a specific  level  of  architecture  definition.  This  includes  the  appropriate 
traffic  analyses  and  the  derivation  of  function  design  characteri sties . These 
activities  are  supported  by  the  refinement  and  expansion  of  the  data  flow 
diagrams  initiated  by  Task  1 and  the  development  of  associated  data 
dictionaries.  This  supporting  material  is  included  in  Appendices  D & E. 
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OF  POOP:  Qua  my 

A key  element  of  the  design  process  is  the  transf ormation  of  functional  and 
performance  requirements  into  design  characteristics  that  can  be  used  to 
"size"  the  system.  This  generally  requires  making  certain  algorithmic 
assumptions  about  how  a function  will  be  implemented  and  the  level  of  implied 
automation.  Design  characteristics  include  such  essential  information  as 
instruction  rates,  timing,  memory,  sequencing,  enablements,  etc.  The  set  of 
design  characteristics  estimated  for  each  function  is  shown  in  Figure  2.3-2. 
These  design  characteristics  have  been  entered  into  our  automated  functions 
data  base  and  a complete  tabulation  is  included  in  Appendix  G.  The  process  of 
estimating  these  design  characteristics  is  based  on  a number  of  available 
models  including  similar  programs  (Shuttle,  Space  Telescope,  Spacelab,  etc.), 
and  related  NASA  studies  as  well  as  engineering  judgements  derived  from  team 
experience . 
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IOC—  O KBYTES 
IQC=  11 


DATA  REQUIREMENT: 
DATA  STORAGE:  SECONDARY: 
PERISHABILITY; 

ARCHIVAL: 

» OF  DISPLAYS: 


INTERVAL*  29E3  SEC 
GROWTH*  1.0  ki pc 
GROWTH*  1 /MIN 
GROWTH*  4 KBYTES 
GROWTH*  5 KBYTES 
GROWTH*  0 KBYTES 
GROWTH*  07.  IN  O HRS 
GROWTH*  O KBYTES 
GROWTH*  11 


Figure  2.3-2.  Design  Characteristics  Data  Base  Format 


2.3.2  Partitioning/Allocation 

Fundamental  to  the  system  definition  effort  is  the  partitioning  and  allocation 
process.  This  is  the  process  of  gradually  dividing  a complex  problem 
(described  by  requirements)  into  logical  groupings  that  can  be  allocated  to 
physical  locations  and  resources.  Again,  this  is  an  incremental  process 
consistent  with  the  design  approach  previously  described. 
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The  end  result  is  the  allocation  of  functions  and  their  associated 
requirements  and  design  characteristics  to  realizable  computational/storage 
resources . However,  this  process  must  consider  many  factors  other  than 
resource  utilization  that  will  directly  contribute  to  system  performance, 
cost-effectiveness  (life-cycle),  risk,  maintainability,  and  growth  potential. 
The  primary  criteria  applied  to  the  various  steps  of  partitioning  are 
identified  in  Table  2.3-1.  The  specific  rationale  applied  to  partitioning  and 
allocation  decisions  will  be  described  in  subsequent  sections  of  this  report. 


Table  2.3-1 . Functional  Partitioning  Guidelines 


Design  Step 

Specific  Partitioning  Criteria 

Generic  Criteria 

1.  Space/Ground 

• See  Autonomy/Automation 

• Autonomous,  Stand-Alone 

Architecture 

Trade  Study  Criteria 

Development 

2.  Network 

• Operational  Concepts 

• Minimize  Interface  Complexity 

Architecture 

• NASA  Organizational  Structure 

• Measurable  and  Testable 
Interfaces 

• Institutional  Resources 

• Time  Phasing  of  Buildup  to  IOC 

3.  Local  Area 

• Functional  Criticality  (Onboard) 

• Data  Base  Access  and  Sharing 

Architecture 

• Different  Computational 

• Response  Time  Requirments 

Structures 

e Isolate  Cooperative/Highly 

• Equivalent  Resource 

Dependent  Functions 

Characteristics 

e Facilitate  Growth  and 

• HW/SW  Commonality 

Technology  Insertion 

• Technical  Disciplines 

e Sequential  Control  Structures 

• Specialized  Capabilities  (I/O,  Al 

Machine,  FFT,  Etc.) 

2.3.3  Design  Synthesis 

Design  synthesis  is  the  formulation  of  physical  design  structures  that  apply 
hardware  resources  (processors,  storage,  interconnections)  and  software 
techniques  to  the  implementation  of  partitioned  requirements . The  alternative 
techniques  and  technologies  that  are  applicable  to  these  design  structures 
were  developed  and  characterized  by  Task  2 (options  development).  While 
partitioning  strives  to  decompose  a system  into  logical  groupings,  design 
synthesis  tends  to  "recombine"  these  groupings  within  the  context  of  a system 
design.  The  adequacy  of  design  concepts  (network  topology,  processor 
throughput,  storage  capacity,  interconnection  bandwidth)  tend  to  constrain  the 
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way  in  which  a system  is  partitioned  and/or  synthesized.  Therefore,  this 
activity  must  be  highly  interactive  with  the  partitioning  process  to  result  in 
a design  that  is  realizable  as  well  as  cost-effective  and  growth  supporting. 

In  a distributed  environment  (either  geographically  or  locally),  this 
interaction  is  extremely  important  since  there  are  many  potential  advantages 
of  system  networking  that  can  be  exploited  through  proper  partitioning.  There 
are  also  potential  disadvantages  that  must  be  identified  and  managed.  These 
advantages/disadvantages  will  be  quantified  in  subsequent  sections  of  this 
report . 


2.3.4  Design  Evaluation 

An  essential  element  of  system  definition  is  the  quantification  of  key  design 
attributes  that  measure  a system's  ability  to  cost-effectively  satisfy 
requirements . In  a well-balanced  design  approach  this  includes  cost 
estimation  and  risk  assessment  as  well  as  performance  measurement  and  the 
determination  of  physical  characteristics . These  programmatic  concerns  (cost 
and  risk)  are  primary  criteria  for  all  trade  studies  and  key  design  decisions. 
A credible  design  evaluation  for  a system  as  complex  as  the  SSDS  can  often  be 
greatly  enhanced  by  the  proper  use  of  simulation  and  modeling  techniques. 

Such  techniques  are  only  as  good  as  the  models  employed  but  they  can  provide  a 
level  of  insight  that  cannot  be  easily  attained  through  analyses.  This  is 
especially  true  for  distributed  systems  where  relatively  complex  network 
interactions  are  important  design  attributes  (buffer  sizing,  response  times, 
resource  utilization,  interference  effects,  etc.)  and  are  difficult  to 
quantify.  Due  to  modeling  uncertainties  that  are  prevalent  at  this  stage  of 
program  development,  such  tools  and  techniques  will  not  provide  absolute 
"answers".  Their  real  value  is  in  providing  a "relative"  assessment  of 
alternative  concepts  to  support  trade  studies  and  key  design  decisions.  Two 
primary  levels  of  simulation  have  been  developed  to  support  SSDS  design 
evaluation.  This  includes  an  end-to-end  network  simulation  using  the  Data 
System  Dynamic  Simulation  (DSDS)  and  several  LAN  simulations.  These  modeling 
capabilities  and  their  assumptions  are  described  in  Appendix  F. 

2.4  Growth  Accommodation 

This  Preliminary  System  Definition  Report  provides  SSDS  design  concepts  for  an 
IOC  space  station.  However,  this  should  not  imply  that  SSDS  growth 
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considerations  have  been  ignored  in  the  process.  A primary  goal  of  this  study 
is  to  develop  an  IOC  system  definition  that  will  cost-effectively  grow  to 
support  anticipated  future  needs.  In  fact,  the  system  definition  process  must 
include  a "Design-To-Growth"  (DIG)  philosophy.  This  approach  recognizes  the 
basic  uncertainties  associated  with  future  requirements  (core/mission), 
projected  technology  capabilities,  and  the  impact  of  significantly  enhanced 
levels  of  autonomy /automation  that  are  necessary  to  develop  a credible 
"optimum"  design.  It  also  recognizes  the  inadequacy  of  merely  relying  on  such 
broad  concepts  as  modularity,  standardization  and  extendabi lity . 

The  DTG  approach  is  based  on  two  key  principles:  (1)  maintain  a "growth 

perspective",  and  (2)  build  growth  considerations  into  all  aspects  of  the 
design  process.  The  "growth  perspective"  is  established  through  the 
requirements  definition  (Task  1)  and  the  options  development  (Task  2) 
activities.  Requirements  and  design  characteristics  have  been  developed  that 
reflect  not  only  anticipated  expansion  of  mis3ion/core  needs  but  also  the 
transition  to  high  levels  of  autonomy /automation  during  growth  phases.  In 
addition,  a "growth  scenario"  was  developed  to  establish  design  goals  and 
objectives.  The  options  development  task  has  identified  and  characterized 
those  technologies  that  could  significantly  influence  future  growth  via 
technology  insertion.  This  technology  profile  contributes  to  an  SSDS  growth 
path  that  is  a balance  of  design  extendability  and  technology  infusion.  The 
technology  recommendations  provided  in  section  9.0  are  intended  to  enhance  the 
SSDS  growth  scenario. 

Growth  considerations  are  integrated  directly  into  the  system  definition 
process  including  all  supporting  activities.  All  trade  studies  (Task  3)  will 
include  growth  (extendable  design  and  technology  insertion)  as  a key  criteria 
that  will  be  highly  weighted.  Trade  study  recommendations  will  include  growth 
as  well  as  IOC  preferences.  The  system  definition  steps  previously  described 
in  this  section  will  also  include  the  following  DTG  considerations. 

1 Requirements  Analysis  - The  derivation  of  function  design 

characteristics  and  traffic  analyses  will  consider  the  implications 
of  enhanced  autonomy/automation  and  increased  mission/core 
requirements . 
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2-  Partitioning/ Allocation  - Growth  (design  extendabi 1 ity  and  technology 
insertion)  is  a key  partitioning  criteria  to  be  applied  at  all  levels 
of  system  decomposition,  from  top-level  architecture  to 

proces sor/storage  allocation.  Specifically,  this  will  include  the 
accommodation  of  advanced  automation  that  is  likely  to  enhance 
station  autonomy. 

3-  Design  Synthesis  - All  key  design  decisions  will  consider  the 
implications  of  growth.  Design  concepts  will  be  formulated  for  a 
proposed  growth  scenario. 

4.  Design  Evaluation  - Proposed  design  solutions  will  be  tested  against 
growth  scenarios  that  include  technology  profile  accommodation  as 
well  as  anticipated  design  extensions  (i.e.,  added  resources  to  a 
module,  added  modules  to  existing  network,  etc.). 

Particular  attention  will  be  focused  on  ways  in  which  advanced  automation  (AI 
technology)  can  be  promoted  by  the  IOC  configuration  and  its  growth 
capability.  This  will  include  the  infusion  of  related  technologies  such  as  AI 
machines  and  knowledge  data  base  storage. 

2 . 5 Design  Traceability 

The  merit  of  an  architectural  design  can  be  measured  by  its  ability  to  satisfy 
all  system,  functional  and  performance  requirements  in  a cost-effective 
manner.  To  accomplish  this  requires  that  all  key  design  decision  can  be 
traced  to  driving  requirements  and  that  all  requirements  can  be  clearly 
allocated  to  design  components.  This  level  of  visibility  is  necessary  not 
only  for  design  evaluation,  but  also  to  identify  sensitivities  for  potential 
requirements/design  tradeoffs  and  to  accommodate  future  requirement 
updates/modifications.  The  system  definition  described  in  this  document 
includes  the  identification  of  driving  requirements  that  directly  influence  a 
key  design  decision.  In  addition,  many  such  decisions  are  supported  by 
detailed  trade  studies  and  analyses.  These  trade  studies  include  relevant 
requirements  and  derived  design  characteristic? . 
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The  primary  means  for  establishing  visible  linkages  between  requirements  and 
the  design  process  is  through  functional  allocation.  This  is  supported  by  the 
SSDS  Functionally  Automated  Database  System  (FADS)  that  provides  the 
capability  to  extract  functions,  requirements,  and  design  characteristics  that 
are  currently  allocated  to  an  SSDS  entity  (elements,  facilities,  modules, 
subsystems).  This  includes  physical  (i.e.,  module)  as  well  as  logical  (i.e,, 
subsystem)  allocations.  FADS  will  extract  information  based  on  functional 
allocation  and  generate  a "mini spec"  as  summarized  in  Figure  2.5-1.  The 
current  function  allocation  matrix  for  the  SSDS  is  included  in  Appendix  H. 
Summary  reports  can  be  generated  for  all  onboard  subsystems,  for  each  SS 

module  (or  external  entity),  or  for  each  element  (DHC,  POCC,  RDC,  etc.)  of  the 
SSDS.  The  mechanism  for  establishing  functional  allocation  is  extremely 
flexible  and  will  easily  accommodate  changes  as  tradeoffs  and  design  decisions 
mature.  Since  allocations  may  change  during  build-up  and  growth  phases,  this 
will  also  support  the  development  of  a function  transition  profile  for  growth 
considerations. 


Allocation  Matrix 
Functions  Subsystem 


Functions  Allocated  to 
Selected  Subsystem 


Subsystem  i 

Input/Output  f J— ] 
To  Other 
Subsystems, 
Agencies,  and 
External  Data 


Additional 
Requirements 
For  Subsystem 
Functions 


Figure  2.5-1.  Automatic  Subsystem  Minispec  Generation 
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2 . 6 Supporting  Tools  & Techniques 


This  section  provides  a summary  description  of  key  tools  and  techniques  used 
to  support  the  system  definition.  Where  appropriate,  references  have  been 
included  for  further  description  and/or  supporting  data. 

a.  FADS  - The  FADS  is  a relational  database  system  that  is  organized  by 
SSDS  function  and  includes  procedures  for  generating  various  types  of 
reports.  The  database  includes  function  descriptions,  requirements 
and  design  characteristics . This  database  wa3  initially  established 
by  Task  1 (requirements  definition)  and  appended  to  the  data  base. 
Additional  capabilities  have  been  added  to  support  the  design  process 
(i.e.,  extraction  of  information  by  logical/physical  allocations)  but 
have  been  kept  separate  to  retain  the  functional  integrity  (no 
built-in  design  implications)  of  the  data  base  and  to  facilitate 
changes  in  an  evolving  design  process. 

b.  Data  Flow  Diagrams  (DFD's)  - DFD's  were  initially  developed  by  Task  1 
as  a logical  (nonphysical)  model  of  the  SSDS.  They  specify  precisely 
"what"  the  system  has  to  do,  leaving  the  designer  free  to  specify 
"how"  it  can  be  done.  They  also  promote  communications  between 
requirements  developers,  the  designers  and  the  customers  (NASA, 
etc.).  The  top-level  DFD's  developed  by  Task  1 have  been  refined  and 
significantly  expanded  during  the  requirements  analysis  phase  of 
system  definition.  The  complete  set  of  current  DFD's  is  contained  in 
Appendix  D.  Note  that  DFD  elements  are  numbered  to  facilitate 
correlation  with  the  function  data  base.  DFD's  provide  the  graphical 
model  for  the  connectivity  of  functions  documented  by  FADS. 

c.  Data  Dictionaries  - Data  dictionaries  provide  additional  DFD  related 
documentation  that  make  up  a comorehensive  "picture"  of  a functional 
system  specification.  They  provide  descriptive  information  related 
to  data  storage  and  support  the  formulation  of  database  structures. 
This  capability  ha3  been  automated  within  FADS  and  a complete 
compilation  is  included  in  Appendix  E. 
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d . Simulations/Models  - Simulation  and  modeling  tools  have  been  used 
extensively  to  support  tradeoff  analyses  and  design  evaluation. 
These  capabilities  are  described  in  Appendix  F. 
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3.0  SSDS  TOP-LEVEL  ARCHITECTURE  OVERVIEW 


The  SSDS  is  the  combination  of  hardware  and  software  that  provides  data 
management  services  to  Space  Station  subsystems  and  customers,  both  in  orbit 
and  on  the  ground.  In  general,  the  data  management  services  provided  by  the 
SSDS  are  those  that  are  needed  by  multiple  subsystems  or  customers  and  do  not 
include  customer  unique  services.  Typical  data  management  services  provided 
by  the  SSDS  include  data  transport,  data  processing,  data  storage,  and 
man-machine  interfaces.  Figure  3-1  is  a conceptual  representation  of  the  SSDS 
within  the  wider  scope  of  a Space  Station  Information  System  (SSIS),  where  the 
SSIS  also  includes  customer-  and  subsystem-unique  data  services,  sensors  and 
effectors,  and  institutional  (multi-program)  services. 


l 


Figure  3-1.  SSIS/SSDS  Model 


This  section  provides  a top-level  overview  of  the  SSDS  architecture  that  has 
been  developed  in  the  MDAC/FACC/IBIVRCA  study.  The  architecture  is  defined  in 
terms  of  (1)  system-level  design  concepts  and  assumptions,  (2)  SSDS  external 
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interfaces,  (3)  identification  and  characterization  of  the  elements  of  the 
SSDS,  (4)  functional  allocation  to  elements,  (5)  SSDS  topology/connectivity, 
and  (6)  an  overview  of  SSDS  operational  concepts.  An  overview  of  key  design 
drivers  that  have  been  identified  is  also  included.  The  onboard  and  ground 
segments  of  the  SSDS  architecture  are  defined  in  considerable  detail  in 
sections  6 and  7,  respectively.  An  end-to-end  SSDS  design  perspective  is 
presented  in  section  4. 

3 . 1 System-Level  Design  Concepts  and  Guidelines 

During  the  course  of  our  study  we  have  been  guided  by  NASA's  goals  and 
objectives  for  the  Space  Station  program.  Ule  have  evaluated  these  goals  and 
objectives  with  respect  to  their  meaning  to  the  SSDS  and  have  derived  a set  of 
requirements # design  concepts  and  guidelines  that  are  appropriate  to  ensuring 
that  the  objectives  are  met.  These  concepts  and  guidelines  have  been  used  to 
influence  the  architecture  selection  and  are  recommended  as  design  policy 
statements  to  be  used  in  future  Space  Station  data  system  design  and 
development  activities.  The  critical  objectives  and  corresponding 
concepts/guidelines  are  described  in  the  following  paragraphs. 


3.1.1  Autonomy /Automat ion 

The  SSDS  architecture  definition  for  IOC,  as  well  as  evolutionary  growth, 
requires  a comprehensive  understanding  of:  (1)  NASA  goals  and  objectives  for 
space  station  autonomy/automation,  (2)  the  technology  that  can  be  applied  to 
achieve  these  goals  and  objectives,  (3)  the  specific  application  areas  most 
appropriate  for  advanced  automation,  and  (4)  the  implications  that  these 
decisions  have  on  SSDS  architectural  design  (Table  3-1  contains  NASA-provided 
terminology  related  to  this  discussion). 

NASA  goals  and  objectives  related  to  autonomy /automation  were  assumed  to  be 
those  expressed  in  the  recent  Advanced  Technology  Advisory  Committee  (ATAC) 
reports.  The  stated  goal  is  to  "create  and  use  a new  generation  of  machine 
intelligence,  robotics  and  automation"  to  maximize  space  station  functional 
capability  and  to  promote  technology  for  potential  terrestrial  applications. 
Since  advanced  automation  concepts  are  not  well  understood  today  (although 
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Table  3-1 


AUTONOMY:  The  ability  to  function  as  an  independent  unit  or  element,  over 

an  extended  period  of  time,  performing  a variety  of  actions  necessary  to 
achieve  pre-designated  objectives,  while  responding  to  stimuli  produced  by 
integrally-contained  sensors. 

AUTOMATION:  The  ability  to  carry  out  a pre-designated  function  or  series 
of  actions,  after  being  initiated  by  an  external  stimulus,  without  the 
necessity  of  further  human  intervention. 

ROBOTICS:  The  technology  by  which  machines  perform  all  aspects  of  an 

action,  including  sensing,  analysis,  planning,  direction/control , and 
effecting/manipulation,  with  human  supervision. 

ARTIFICIAL  INTELLIGENCE:  A discipline  which  attempts  to  simulate  or 

duplicate  the  efficient  problem-solving  capabilities  of  humans. 


substantial  progress  is  being  made),  the  IOC  capability  should  "be  designed  to 
capture  as  many  advanced  concepts  that  are  necessary  and  available  today  while 
allowing  for  the  hardware  scars  and  the  software  hooks  that  will  be  needed  to 
accept  the  developing  technology".  The  report  also  identified  specific 
objectives  that  included  the  extensive  use  of  expert  systems  for  all  onboard 
subsystems.  The  goals  and  objectives  for  autonomy /automat ion  will 
significantly  influence  the  onboard  SSDS  architecture  in  the  following  key 
areas : 

a.  Partitioning/allocation  of  SSDS  functions  to  promote  NASA's  IOC 
autonomy/automation  goals. 

b.  Architecture  to  accommodate  evolutionary  growth. 

c.  Adequate  onboard  resources  (processing,  storage)  to  support  advanced 
automation  for  IOC. 
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The  final  ATAC  technical  reports  were  not  available  in  time  to  comprehensively 
factor  into  this  document  and  the  system  definition  presented  here  is  based  on 
internal  trade  studies.  However,  the  influencing  factors  identified  above 
have  been  addressed  in  the  system  definition  process.  The  key  difference  is 
that  onboard  subsystem  resources  were  "sized"  based  on  conventional  automation 
algorithms  rather  than  ATAC  recommended  expert  system  implementation.  These 
algorithmic  characteristics  are  certainly  better  understood  and  more 
available.  Sufficient  resource  margin  has  been  provided  in  the  conceptual 
design  but  the  adequacy  of  these  resources  for  broad  application  of  expert 
systems,  as  recommended  by  the  ATAC  reports,  will  be  investigated  in  future 
study  activities. 

Recognizing  the  influence  that  autonomy /automation  concepts  must  have  on  the 
design  process,  several  key  trade  studies  were  initiated  early  in  the  SSDS 
architecture  study.  These  highly  interrelated  studies  (illustrated  in  Figure 
3-2)  result  in  the  following. 

a.  Function  Automation  - Determine  degree  of  automation  appropriate  for 
all  SSDS  functions  (IOC  and  growth). 

b.  Space  Autonomy  - Allocation  of  SSDS  functions  to  space  and/or  ground 
(IOC  and  growth). 

c.  AI  Automation  - Given  that  a function  is  to  be  automated,  determine 
if  AI  or  conventional  techniques  should  be  applied  (IOC  and  growth) . 

These  trade  studies  are  highly  interactive  and  form  the  basis  for  many  key 
design  decisions.  The  preliminary  results  of  these  studies  are  provided  in 
the  Task  3 report.  The  degree  of  automation  and  the  application  of 
Al/conventional  techniques  are  manifest  in  the  function  design 
characteristics . The  allocation  of  functions  to  space/ground  elements 
provides  the  basis  for  further  partitioning/allocation. 

The  AI  automation  study  focused  primarily  on  the  application  of  expert  systems 
and  did  not  address  other  areas  such  as  robotics,  etc.  Expert  system 
approaches  were  weighed  against  conventional  approaches  for  the  SSP  in  terms 
of  cost,  risk  and  required  resources.  It  did  not  address  the  more  global 
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Options  (Task  2)' 


Figure  3-2.  Autonomy/ Automation  Trade  Study  Interaction 


goals  of  the  ATAC  associated  with  the  development  of  a technology  base  for 
"terrestrial  applications".  The  preliminary  results  of  the  trade  study 
recommended  functions  as  candidates  for  IOC  and  growth  advanced  automation. 
Some  of  these  functions  are  in  addition  to  those  identified  by  ATAC  and  are  of 
considerable  magnitude  and  complexity  (planning/scheduling).  However,  while 
technically  challenging,  their  implementation  would  advance  the  general 
state-of-the-art  for  expert  systems  and  potentially  result  in  significant  cost 
savings.  We  have  focused  on  the  planning/scheduling  function  because  of  the 
very  large  potential  payoff  in  operational  man-hour  savings. 

Subsystem  autonomy  onboard  the  Space  Station  is  enabled  and  promoted  by 
several  features  of  the  proposed  onboard  SSDS  architecture  including  the 
following:  (1)  standard  data  processors  (SDP's)  that  can  be  dedicated  to 

subsystem  application  processing,  (2)  SDP  operating  systems  that  provide  a set 
of  easy-to-use  and  eavy-to-understand  services  for  subsystem  applications 
software,  (3)  a primary  data  network  (bus,  NIU,  NOS)  that  provides  subsystems 
with  a predictable,  responsive,  high-capacity  data  transport  service,  and  (4) 
a set  of  DMS  user  support  services  such  as  data  base  maintenance  and  access, 
man-machine  interface,  caution  and  warning,  and  time  management  and  reference 
signal  distribution. 
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In  summary,  our  preliminary  architecture  incorporates  a high  degree  of  space 
and  subsystem  autonomy,  includes  selected  advanced  automation  features  for 
IOC,  and  provides  for  the  growth  of  automation  throughout  the  Space  Station 
lifetime.  Additional  study  will  assess  the  increased  use  of  AI  automation  in 
the  IOC  system. 

3.1.2  Standard ization/Commonali tv 

Standardization  and  commonality  are  consistently  promoted  as  attributes  that 
will  help  the  Space  Station  program  achieve  its  cost  and  productivity  goals. 

The  following  definitions  for  these  terms  have  been  developed  to  guide  our 
study . 

Standardization  is  the  process  of  developing  a uniform  hardware,  software, 
interface,  or  procedural  approach  and  enforcing  its  use  across  a set  of 
similar  applications. 

Commonality  is  the  property  that  two  or  more  applications  or  systems  have 
when  they  incorporate  identical  sub— elements  (hardware  or  software  units). 

Standardization  of  hardware  and  software  elements  enables  commonality  between 
subsystems  and  systems.  Commonality  can  be  an  important  factor  in  controlling 
development  costs  in  a large  program  by  reducing  or  eliminating  parallel 
development  of  similar  items.  Commonality  can  reduce  operational  costs  by 
reducing  the  training  and  spare  parts  costs.  Commonality  can  also  improve 
system  reliability  and  availability  by  allowing  non-critical  applications  to 
serve  as  backup  to  critical  units. 

Standardization  has  additional  benefits,  including  improved  user  familiarity, 
and  more  efficient  and  effective  integration  of  new  payloads  and  subsystems. 
The  key  to  achieving  these  benefits  is  the  selection  of  appropriate  data 
communications  standards.  These  standards  define  how  a user  will  interface 
with  the  SSDS  to  take  advantage  of  the  SSDS  services. 

Data  system  communications  standards  are  applicable  in  three  major  areas  in 
the  end-to-end  architecture : 
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• Flight  segment  local  area  networks 

• TDRSS  uplink/downlink 

• Terrestrial  local  area  and  wide  area  networks 

Needs  for  customer/user  transparency , efficient  high  speed  protocol 
translation,  and  eventual  migration  of  ground  functions  to  the  flight  segment, 
dictate  that  these  standards  and  related  conventions  be  as  compatible  as 
possible  across  all  three  sets  of  network  components.  The  proposed  approach 
to  achieving  this  is  in  an  end-to-end  architecture  that  is  described  in 
Section  4.  The  ISO/OSI  reference  model  is  utilized  in  this  description. 

The  primary  set  of  standards  likely  to  be  of  use  for  lower-level  ISO  layer 
flight  segment  LAN  standards  are  (1)  the  IEEE  802  family  of  protocols  which 
include  multiple  physical  link  protocols  united  by  a common  logical  link 
control  protocol  (IEEE  802.2)  and  (2)  the  emerging  100  Mbps  ANSI  X3T9.5  fiber 
optic  physical  and  data  link  protocols.  Although  the  collision  sense  and 
token  ring  protocols  associated  with  IEEE  802  may  not  be  appropriate  under  the 
constraints  of  bandwidth  requirements  for  the  SSDS,  the  use  of  the  medium 
access  and  logical  link  control  protocols  are  appropriate. 

The  TDRSS  and  direct  user  links  essentially  should  be  viewed  as  noisy  links 
between  the  onboard  and  ground  ISO/OSI  networks.  The  selection  of  standards 
for  these  links  is  driven  by  the  limitations  of  the  underlying  physical 
links.  It  is  recommended  that  the  current  CCSDS  standards  be  used  for  these 
links  with  the  choices  of  the  many  various  options  supported  within  the  CCSDS, 
and  that  uplink/downlink  protocol  conversion  be  supported  as  outlined  in 
Section  4.  The  telemetry/telecommand  standards  should  be  adopted  as  SSDS 
standards.  While  customers  may  format  the  internal  content  of  their  data  in 
any  way  they  wish,  the  basic  structures  of  the  telemetry  formats  should  be 
adhered  to  and  the  SSDS  must  certify  that  the  payloads  are  in  fact  formatting 
the  data  properly.  The  SSDS  may  consider  providing  source  code  to  do  the 
formatting  of  the  customer  data.  Core  data  should  adhere  to  additional 
internal  format  standards  for  identification  of  measurement  data  as  described 
in  Section  7. 

The  need  for  a symmetric  uplink/downlink  capability  is  particularly 
important.  This  implies: 
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• providing  all  services  (such  as  verified  vs  unverified  delivery)  in 
both  directions 

0 using  the  same  packet/frame  format  in  each  direction  (currently  the 
formats  are  different  for  the  uplink/downlink) 

• implementing  an  addressing  scheme  that  can  be  used  for  either  space 
or  ground 

In  addition,  the  possibility  of  augmenting  these  telemetry/telecommand 
standards  should  be  examined  so  that  the  following  are  customer  selectable 
options : 

• quality  of  transport  service  (bit  error  rate) 

• delivery  service  (immediate  delivery  vs  store  & forward  delivery) 

• reliability  services  (verified  vs  unverified  delivery) 

The  ground  segment  LAN's  are  likely  to  be  significantly  less  uniform  than  the 
flight  segment  LAN's.  The  IEEE  802  family  seems  to  provide  the  most 
straightforward  set  of  solutions,  since  they  provide  a broad  set  of  physical 
link  layer  solutions,  and  have  been  implemented  on  most  major  vendors' 
processors.  Additional  physical  layer  protocols  (e.g.,  fiber  optics 
protocols)  can  be  provided  for  enhanced  bandwidth,  but  maintaining  the  same 
data  link  layer  protocols. 

A leading  candidate  for  a SSDS  wide  area  standard  for  "low  speed"  data  is  the 
X.25  packet  standard.  Current  commercial  implementations  of  X.25  provide 
service  at  rates  up  to  56  kilobits  per  second.  Although  higher  data  rates  are 
feasible,  the  bandwidth  of  X.25  is  constrained  by  feasible  switching  rates, 
buffering  requirements , and  handshaking  procedures.  It  is  unlikely  that  rates 
over  a megabit  per  second  can  be  supported  with.n  the  forseeable  future.  In 
addition,  portions  of  the  network  (e.g..  White  Sands  to  Regional  Data  Center) 
may  only  require  relatively  static  routing  capabilities  (permanent  real  or 
virtual  circuit  standards).  For  higher  speed  data,  circuit  switching 
standards  or  connectionless  ("datagram")  standards  may  be  most  appropriate. 
Another  feasible  alternative  is  to  define  multiple  classes  of  X.25  services, 
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removing  elements  of  the  X.25  protocol  (e.g.,  dynamic  routing  or 
acknowledgement  services)  in  order  to  achieve  satisfactory  performance  for 
various  data  rates.  The  high  rate  experiments  may  or  may  not  be  sent  in  the 
form  of  telemetry  packets  and  wide  area  standards  for  this  data  may  be  limited 
to  transport  standards. 

For  the  ground  segment  it  thus  appears  feasible  to  adopt  an  evolutionary 
approach  to  selection  of  standards,  expanding  the  quality  of  services  as 
packet  switching  technology  improves.  A distinction  between  high  and  low  data 
rate  services  that  is  technology-dependent  could  be  adopted;  high  data  rates 
would  simply  be  defined  as  those  for  which  standard  X.25  services  could  not  be 
provided  with  off-the-shelf  switching  equipment.  High  data  rate  users  would 
be  limited  to  non-dynamic  services  although  they  would  have  access  to  low  rate 
command  and  data  transfer  channels  which  would  provide  fully  transparent 
packet  network  support.  As  switching  technology  improves  (or  as  new  high 
performance  packet  standards  are  introduced)  further  capabilities  for  high 
rate  services  could  be  introduced  with  the  net  effect  of  removing  the 
distinctions  between  high  rate  and  low  rate  services  and  standards. 

The  standards  selected  for  direct  interface  to  customers  should  be  in 
conformance  with  the  ISO/OSI  model  and  should  use  commercially  available 
standards  if  possible.  Thus  if  NASA  specific  standards  are  used  within  the 
data  distribution  networks,  the  SSDS  should  support  protocol  conversion  to 
commercial  standards  before  delivery  of  data  to  customers. 

These  data  communications  standards  are  necessary  in  the  Space  Station  program 
so  that  the  user  can  effectively  plan,  develop,  integrate,  and  utilize  their 
Space  Station  experiment  or  application.  A continuing,  focused  effort  is 
needed  to  further  define,  publicize,  explain,  update,  and  maintain  these 
standards . 

There  are  several  promising  areas  for  commonality  that  have  been  identified, 
including  data  processing  hardware,  operating  systems,  programming  language, 
user  command  and  control  language,  and  work  station  hardware.  While  it  is 
recognized  that  growth  versions  of  the  SSP  will  certainly  have  to  accommodate 
heterogenous  data  system  elements,  it  is  concluded  that  the  IOC  and  growth 
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planning  for  a large  degree  of  standard ization/commonality  should  be 
followed.  This  is  particularly  true  for  the  SSP  Subsystems.  Rigid 
justification  procedures  for  any  waivers  should  be  established.  At  this  point 
in  the  development  it  is  not  likely  that  the  "off-the-shelf"  excuse  can  be 
made  palatable.  The  need  for  subsystem  development  and  testing  independence 
will  still  allow  the  enforceability  of  standards/commonality  especially  at 
levels  such  as  accepted  data  bus  standards  and  processor  Standard  Instruction 
of  Architectures  (ISA's).  Further  discussion  on  selection  and  application  of 
standards/commonality  is  included  in  Section  6 and  7.  The  results  of 
applicable  trade  studies  are  in  the  Task  3 report. 

3.1.3  Security/Privacy 

Security  and  privacy  are  defined  as  follows: 

Security  is  the  protection  of  SSDS  resources,  data,  and  information  1) 
from  damage,  2)  from  disclosure  to  unauthorized  individuals,  and  3) 
against  unauthorized  modification. 

Privacy  is  the  limitation  of  access  to  data  or  information  to  some  level, 
short  of  a complete  guarantee  as  implied  by  the  term  security. 

A key  design  driver  with  respect  to  security/privacy  implementation  is  an 
assessment  of  both  the  threats  to  security/privacy  and  the  relative  value  of 
data,  or  loss  if  its  privacy  is  violated. 

The  threat  assessment  involves  evaluation  of  the  likelihood  of  various  types 
of  security/privacy  violation  at  each  node  and  for  each  data  type  within  the 
SSDS  network.  The  threat  categories  include  potential  physical  damage  as  well 
as  logical  penetration  of  implemented  safeguards. 

The  value  assessment  is  the  association  of  a value  to  each  type  of  data  and 
information,  or  equivalent,  and  a loss  value  for  breach  of  security/privacy 
for  each  data  or  information  type.  This  assessment  highlights  those  SSDS 
areas  most  in  need  of  protection,  thereby  most  impacting  SSDS  design 
features.  The  differing  value  of  customer  data  suggests  that  differing  levels 
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of  privacy  protection  will  be  implemented  within  the  SSDS  depending  on  data 
type  and  customer. 

Detailed  threat  and  data  value  assessments  have  not  been  performed.  A NASA 
threat  assessment  is  being  performed  under  contract  to  Kennedy  Space  Center 
(KSC)  and  will  be  available  in  preliminary  form  for  the  Phase  B contractors  by 
the  end  of  calendar  year  1985.  As  the  KSC  threat  assessment  matures,  and  as 
the  customer  base  solidifies  and  their  data  privacy  requirements  become  known, 
possible  security/privacy  impacts  on  the  SSDS  design  will  need  to  be 
reassessed . 

The  following  key  policy  statements  define  the  basic  framework  for  the 
security/privacy  impacts  on  the  present  SSDS  system  design.  Key  policy  issues 
are  presented  subsequently. 

1.  Different  nodes  and  communication  paths  will  require  different  levels  of 
security/privacy . Protection  of  the  Space  Station  base  and  platforms  is 
accorded  the  highest  priority  with  respect  to  secure  commanding  and 
operations,  i.e.,  the  highest  levels  of  SSDS  security  required  are  for 
onboard  resource  control  and  operations  authorizations.  The  ultimate 
control  for  onboard  decisions  is  presumed  to  rest  with  the  crew,  with 
ground  takeover  possible  if  the  crew  become  incapacitated. 

2.  The  SSDS  will  assure  privacy  of  data,  audio,  and  video  links,  but  not 
ultimate  security  of  customer  information. 

3.  The  user  is  responsible  for  higher  levels  of  information  content 
protection.  Encryption  is  one  technique  available  to  the  user.  The  SSDS 
will  facilitate  user  implementation  of  encryption  by  providing  standard 
interfaces  for  encryption  equipment. 

4.  No  military  security  requirements  are  incorporated  into  the  baseline 
design. 

5.  The  key  constraints  which  limit  the  amount  of  privacy/security  provided  as 
a standard  service  are  life-cycle  cost  impacts,  cost  versus  benefit  of 
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protection  by  customer  and  data  class,  and  potential  system  performance 
degradation . 

6.  International  securi ty/privacy  requirements  have  been  assumed  to  be 
contained  within  the  spectrum  of  U.S.  commercial  and  other  user 
requirements . 

Key  Policy  Issues 

1.  The  role  and  extent  of  National  Security  Agency  (NSA)  versus  NASA 
responsibility  for  communications  system  security  needs  to  be  determined. 

2.  The  levels  of  personnel  and  physical  security  at  each  SSDS  node  needs  to 
be  established. 

3.  If  NSA  Trusted  Computer  System  evaluated  subsystems  are  required  for  the 
SSDS,  the  available  computer  system  options  will  be  significantly  reduced. 

4.  NASA,  NSA,  ESA,  etc.,  interagency  coordination  needs  to  be  established  in 
the  area  of  security/privacy  implementation. 

5.  The  extent  of  NASA  cooperation  with  NSA  with  respect  to  encryption  chip 
technology  utilization  and  dependence  needs  to  be  determined. 

6.  Upgradeability  for  possible  future  military  requirements  needs  to  be 
considered  in  the  SSDS  design. 


3.1.4  Evolutionary  Growth 

One  of  the  key  requirements  imposed  on  the  SSDS  is  to  provide  sufficient 
growth  capability  to  support  the  future  needs  of  the  program  in  a 
cost-effective  manner.  This  includes  growth  in  functional  capability, 
available  internal  resources,  and  the  ability  to  handle  increased  external 
interface  demands.  While  applicable  to  both  ground  and  space  elements,  the 
primary  focus  is  on  the  more  constrained  environment  of  space  where 
improvements  and  new  capabilities  may  be  accommodated  by 
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modif ication/replacement  of  existing  modules  or  the  addition  of  new  ones.  In 
any  case,  it  must  be  recognized  that  future  data  system  needs  over  the 
expected  life-time  of  the  space  station  cannot  be  accurately  forecast  and  it 
will  be  difficult  to  determine  “how  much"  growth  potential  is  adequate. 
Therefore,  SSDS  architectural  concepts  need  to  consider  multiple  mechanisms 
for  accommodating  growth.  The  key  growth  objectives  for  the  SSDS  may  be 
summarized  as  follows: 

1.  The  SSDS  should  facilitate  growth  in  data  service  requirements 
throughout  the  life  of  the  Space  Station. 

2.  The  SSDS  should  facilitate  the  insertion  of  new  technology. 

3.  The  SSDS  should  support  the  evolution  to  higher  levels  of  autonomy 
and  automation. 

The  system  developer’s  viewpoint  of  the  space  station  evolutionary  process  is 
that  phased  development,  new  customers  and  improvement  needs  will  result  in 
data  system  requirements  for  more  increased  functional  capability  and/or 
resources.  This  section  describes  the  concepts  for  extending  the  SSDS 
capability  to  meet  these  requirements . An  alternative  viewpoint  from  the 
customer  perspective,  however,  is  that  “growth"  can  be  measured  in  terms  of 
increased  information  derived  from  mission  data.  This  can,  of  course,  have 
the  same  effect  as  the  traditional  viewpoint  if  the  result  is  increased  data 
rates  requiring  additional  SSDS  functional/resource  capabilities.  The 

“information  content”  of  the  mission  data  handled  by  the  SSDS  could  also  be 
improved  through  additional  onboard  payload  data  processing  and/or  data 
compression  without  necessarily  increasing  data  rates.  This  could  be 
particularly  beneficial  if  applied  to  the  high  data  rate  missions.  It  is  not 
likely  that  such  payload  unique  functions  would  be  included  in  the  SSDS; 
however,  they  must  be  considered  in  a well-balanced,  evolutionary  process  as  a 
viable  alternative  to  SSDS  expansion. 

The  SSDS  architecture  concepts  that  we  recommend  to  enhance  growth  capability 
are  the  following. 
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1 . Partition  systems,  subsystems,  and  modules  for  maximum  functional 
autonomy  at  each  level.  The  critical  partitioning  task  determines 
the  degree  of  autonomy  of  each  functional  module,  and  hence,  the  ease 
by  which  it  can  be  replaced  or  expanded  for  growth  reasons  without 
intei — related  impacts  on  other  elements. 

2.  ft  hierarchial  organization  of  processing  elements.  This  approach 
supports  both  vertical  and  horizontal  expansion  and  allows  functional 
autonomy . 

3 . Selection  and  enforcement  of  widely-accepted  standards  for 
interfaces,  communication  protocols,  languages,  etc.  The  standards 
that  are  selected  must  have  widespread  support  and  staying  power  in 
the  commercial  and/or  DOD  areas. 

4 . Extensive  "hooks  and  handles"  in  the  IOC  hardware  and  software. 
Machine-readable  test-points,  status  monitors,  environmental 
monitors,  and  unit  identifiers  are  examples  of  these  "hooks  and 
handles"  that  are  needed  to  allow  growth  in  automation. 
Machine-capable  controls  should  be  considered  for  all  IOC  manual 
control  functions  for  the  same  reason. 


5 . Design  features  to  promote  increased  information  content  of  the 
data.  For  example,  allowance  for  special  purpose  data  processors, 
image  data  compression  hardware  and  software,  and  robust 
general-purpose  processing  capability.  (Programmatic  features  such 
as  a user  charge  policy  that  provides  a strong  incentive  for  users  to 
maximize  the  information  content  of  their  data  should  also  be 
considered . ) 

6.  Large  capacity  margins  in  the  IOC  SSDS  backbone  data  networks,  We 
recommend  that  the  capacity  of  the  IOC  core  data  network  and  customer 
data  network  each  exceed  the  expected  IOC  load  by  a factor  of  at 
least  150% 
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These  concepts  have  been  incorporated  in  the  onboard  SSDS  architecture  and, 
perhaps  to  a lesser  extent,  in  the  ground  SSDS  architecture  since  it  does  not 
have  the  same  weight,  power,  volume,  and  accessibility  constraints.  The 
ground  segment,  however,  must  be  uniquely  responsive  to  increasing  automation, 
to  increasing  autonomy  of  the  space  segment,  and  to  changes  in  the 
communications  infrastructure . Program  operating  costs  associated  with  ground 
staffing  will  continue  to  be  a concern.  The  ground  segment  must  accommodate 
this  drive  toward  lower  staffing  by  supporting  increased  space  autonomy  and 
increased  automation  of  ground  functions.  The  concepts  of  modularity  and  use 
of  widely-accepted  standards  are  equally  applicable  to  ground  and  space. 

The  ground  segment  will  also  need  to  adapt  to  changes  in  communications 
capabilities,  such  as  TDRSS  evolution  or  TDAS  in  the  NASA  world,  and  the 
rapidly  changing  commercial  communication  environment.  Examples  of  the  latter 
are  more  and  new  kinds  of  commercial  communications  satellite  service, 
expanding  commercial  fiber  optic  networks,  growing  commercial  digital 
services,  and  new  standards  such  as  Integrated  Services  Digital  Network 
(ISDN).  The  ground  segment  needs  to  be  capable  of  supporting  Space  Station 
data  distribution  in  a way  that  allows  the  program  to  take  advantage  of  the 
performance  and  cost  benefits  of  these  new  commercial  services. 

The  development  of  TDAS  or  a TDAS-like  capability  that  allows  direct  broadcast 
of  Space  Station  data  to  several  regional  sites  will  allow  the  ground  SSDS 
data  capture,  sorting,  and  routing  functions  to  be  re-allocated.  First-level 
sorting  and  routing  would  be  moved  from  the  Data  Handling  Center  to  the  space 
segment.  Data  capture  and  the  next  level  of  sorting  and  routing  would  be 
distributed  to  the  Level  Zero  Processing  Centers.  The  IOC  ground  SSDS 
architecture  allows  this  kind  of  function  re-allocation  and  relocation. 

3.1.5  Transparency .'  The  SSDS  should  have  the  property  that  it  appears  to 
be  "transparent"  to  a user;  that  is,  the  user  should  be  able  to  communicate 
with  his  payload  or  subsystem  via  the  SSDS  such  that  the  SSDS  has  minimal 
affect  on  the  customer  to  payload  interfaces.  For  example,  when  a customer- 
connects  his  work  station  to  his  payload  at  his  facility,  the  operation  should 
be  functionally  identical  to  the  on-orbit  phase  when  the  customer,  at  a work 
station  at  his  facility,  is  interacting  with  his  payload  on  orbit.  Some 
implications  of  this  objective  on  the  SSDS  are  as  follows: 
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• The  SSDS  should  transport  customer-generated  commands  and  data  to  the 
payload  with  no  format  changes  and  with  minimal  delays  and 
constraints.  Any  artifacts  added  by  the  data  transport  service  must 
be  removed  prior  to  delivery  to  the  payload. 

• The  SSDS  should  transport  data  packets  or  messages  from  the  payload 
to  the  customer  with  no  format  changes  and  with  minimal  delays. 
Artifacts  that  are  added  by  the  data  transport  service,  such  as  error 
correction  coding,  bit  reversal,  or  packet  sequence  re-ordering,  must 
be  removed  by  the  SSDS  prior  to  delivery  to  the  customer. 

Several  SSDS  design  concepts  are  suggested  to  promote  the  "transparency " of 
the  system.  These  concepts  include  the  following: 

1.  The  use  of  packet  formats  with  self-contained,  autonomous  packets 
created  by  the  source  (customer  or  payload). 

2.  The  use  of  standard  interface  formats  and  protocols. 

3.  Minimization  of  command  checking  by  the  selection  of  a command 
management  approach  that  allows  most  commands  to  pass  through 
unchecked  and  applies  the  constraint/restriction  checks  to  a small, 
pre-defined  set  of  commands  that  have  mode  (resource)  change 
requirements  or  hazard/safety  potential. 

4.  Excluding  from  SSDS  the  need  to  merge  payload  data  with  data  from 
other  sources  prior  to  delivery  to  the  customer.  This  is  possible  if 
the  external  data  is  made  available  to  the  customer  in  a form  and  at 
a time  that  permits  him  to  do  the  merging  expeditiously  (either 
onboard  or  on  the  ground). 

5.  The  use  of  first-in,  first-out  or  random  access  communication  buffers 
to  avoid  data  reversal. 

6.  Robust  communication  links  to  avoid  or  minimize  delays  due  to 
bandwidth  limits  or  link  unavailability. 
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7.  Real-time  foward  error  correction  coders  and  decoders  to  provide 
essentially  error-free  data  communication. 

8.  A network  operating  system  (NOS)  for  the  onboard  and  ground  LAN's  and 
a wide-area  network  manager  that  provides  a range  of  network  services 
for  the  user  in  an  invisible  manner  to  the  user.  The  network 
services  include  session  control,  network  resource  management, 
routing,  synchronization,  flow  control,  and  error  control.  Section  4 
describes  the  implementation  of  these  services. 

3.1.6  Telescience . Telescience  is  the  capability  for 

scientist/investigators  to  (1)  control  and  monitor  their  space  instrumentation 
from  their  institution  and  (2)  to  have  access  to  data  (bases)  in  many 
locations  for  analysis  at  their  home  institution.  This  concept  involves  near 
real  time  operability,  transparency , data  delivery  and  data  base  access  across 
many  differing  logical  interfaces.  The  system  definition  of  Section  6.0  and 
Section  7.0  accommodates  the  Telescience  concept  a3  detailed  in  Section  4.0. 

3 . 2 SSDS  External  Interfaces 

This  section  describes  the  functional  relationship  between  the  SSDS  and  the 
key  external  elements  that  have  direct  interfaces  with  the  SSDS.  The  concept 
of  SSDS  standard  services  is  discussed  and  the  primary  SSDS  standard  services 
are  described.  A summary  of  the  partitioning  criteria  that  were  used  to  do 
the  interface  functional  partitioning  is  included. 

3-2.1  Identification  of  Interfaces.  Figure  3-1  showed  that  the  SSDS  has 
external  interfaces  with  customers,  payloads,  subsystem  sensors  and  effectors, 
space  station  operators,  and  institutional  services.  These  interface 
categories  are  expanded  in  Table  3,2-1. 

3.2.2  Functional  Partitioning  Guidelines.  For  the  external  interfaces,  the 
functional  partitioning  is  driven  by  the  needs  and  constraints  of  the  external 
element  for  the  case  where  that  element  is  external  to  the  Space  Station 
program.  For  instance,  the  SSDS  must,  for  the  most  part,  adapt  to  the 
existing  capabilities,  interfaces,  and  operational  procedures  for  its 
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Table  3.2-1  SSDS  External  Interfaces 


• Customers 

t 

• Customers  at  customer  facilities 

• Customers  at  POCC's 

• Customers  at  RDC's 

• Customers  onboard  the  Space  Station 

• Payloads 

• On  the  Space  Station 

• On  the  POP 

• On  the  COP 

• Subsystem  Sensors  and  Effectors 

• On  the  Space  Station 

• On  the  POP 

• On  the  COP 


• Space  Station  Operators 

• Onboard  crew 

• At  the  SSOCC,  POPOCC,  or  COPOCC 

• Institutional  Services,  Facilities,  and  Functions 

• NSTS 

• NSTS  Mission  Control  Center 

• TDRSS 

• Network  Control  Center 

• GPS 

• TMIS 

• NORAD 
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interfaces  with  institutional  services  such  as  TDRSS,  GPS,  and  the  NSTS. 
Customer  and  payload  interfaces  must  be  adaptable  to  a wide-range  of  needs, 
capabilities,  and  operational  procedures,  Space  station  operator  interfaces 
are  driven  by  productivity,  flexibility,  training,  safety,  and  system  security 
considerations,  The  subsystem  sensor  and  effector  interface  is  defined  so 
that  all  data  services  that  support  sensors  and  effectors  that  are  generally 
considered  to  be  "general-purpose"  data  processing  have  been  allocated  to  the 
SSDS  and  "special-purpose"  processing  or  signal  processing  functions  are 
allocated  to  the  sensors  and  effectors  side  of  the  interface.  This  last 
guideline  (for  sensors  and  effectors)  should  not  be  taken  as  a recommended 
guideline  for  Space  Station  subsystem  partitioning  but  is  intended  to  provide 
a broadly-scoped  definition  of  the  SSDS.  Table  3.2-2  summarizes  these  key 
partitioning  considerations. 


3.2.3  SSDS  Standard  Services.  The  SSDS  provides  a set  of  standard  services 
for  users  (customers,  operators,  payloads,  subsystems).  The  functional 
interface  definition  is  based  on  the  existence  of  these  standard  services.  It 
must  be  recognized  that,  in  general,  the  use  of  standard  services  by  a Space 
Station  customer  is  optional.  The  customer  may  select  from  the  set  of 
standard  services,  using  the  ones  that  meet  his  needs  and  providing 
alternative  capabilities  when  he  judges  it  necessary  to  achieve  his  objectives. 
In  some  instances,  payloads  will  be  required  to  use  particular  standard 
services  to  insure  that  the  overall  Space  Station  integrity  can  be 
maintained.  For  instance,  a payload  having  a potentially  hazardous  command 
sequence  will  have  its  commands  screened  by  the  SSDS  command  processing 
service  so  that  risk  to  Space  Station  systems  and  crew  are  minimized. 

Table  3.2-3  provides  a summary  of  SSDS  standard  services.  The  generic 
functional  interfaces  described  in  the  next  section  assume  maximum  use  of 
these  services  by  SSDS  users. 

3.2.4  Functional  SSDS  External  Interfaces.  Figures  3-3  through  3-7 
describe  the  major  features  of  the  functional  interfaces  between  the  SSDS  and 
the  major  external  element  categories.  The  description  identifies  the  key 
high-level  functions  assigned  at  each  side  of  the  interface  and  the  types  of 
data  that  must  flow  across  the  interface  to  support  that  functional 
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Table  3.2-2  Partitioning  Guidelines  for 
SSDS  External  Interfaces 


SSDS  Interface  Category 
• Customers  and  Payloads 


• Space  Station  Operators 


• Subsystem  Sensors  and  Effectors 


• Institutional  Services  and 
Facilities 


Functional  Partitioning  Considerations 

• Customer/ pay load  operational  needs 

• Customer/ pay  load  data  rates, 
quantities,  types 

• Customer  development  and  integration 
needs 

• Customer  physical  location 

• Degree  of  Transparency 

• Overall  cost  to  SSP  and  customers 

• Operator  productivity 

• Operator  training  and  skill  level 

• System  safety  and  security 

• Overall  cost  to  SSP 

• Uniqueness  or  generality  of  data 
service  needed 

• Overall  cost  to  SSP 

• Established  systems  and  procedures 

• Overall  cost  to  NASA 


allocation.  Appendix  C contains  an  expanded  description  of  the  functional 
SSDS  external  interfaces. 

3 . 3 SSDS  Element  Identification  and  Characterization 

The  SSDS  resides  in  a more  global  entity  called  the  Space  Station  Information 
System  (SSIS)  which  includes  all  of  the  end-to-end  data  services  for  Space 
Station  customers  and  subsystems.  To  define  the  basic  elements  of  the  SSDS, 
we  began  with  the  basic  set  of  Space  Station  Program  Elements  (SSPE's) 
identified  by  NASA,  including  the  core  manned  station,  co-orbiting  platforms. 
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Table  3.2-3  SSDS  Standard  Services 


Data  Handling 

• Capture  raw  data  and  process  to  level  0 (routine). 

• Provide  a quick-look  capability  for  level  0 data. 

• Process  customer  data  to  level  1A  (customer  option.) 

• Provide  data  analysis  utilities. 

• Provide  data  processing  hardware  and  operating  systems  to  support 
subsystem  applications. 

• Provide  short-term  (customer  delivery  plans  one  week)  archiving  of  level  0 
and  SSDS-produced  level  1A  customer  data. 

• Provide  a two-year  archive  of  engineering/ancillary  data. 

• Provide  catalog,  catalog  query,  inventory,  and  retrieval  services  for  all 
archived  data. 

• Provide  on-line  storage  for  customer  data  for  12  hours. 

Ancillary  Data 

• Collect,  format,  and  process  ancillary  data  (Space  Station  engineering  and 
operations  data). 

• Provide  on-board  time  management  and  time  reference  distribution. 

• Provide  electronic  access  to  ancillary  data. 

• Provide  customers  a means  to  electronically  access  Space  Station 
administrative,  operations,  and  engineering  data  files. 

Data  Distribution 


• Provide  local  (within  a program  element,  e.g..  Space  Station)  and 
wide-area  data  transport  services  to  support  distribution  of  mission, 
engineering,  operations,  command  and  control,  and  other  types  of  data  plus 
audio  and  video  data. 

• Provide  distribution  network  control  services. 

• Provide  a means  for  users  to  request  communications  services. 
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Table  3.2-3  (continued) 


Command  and  Control 


• Provide  standard  work  stations  for  customer  and  operator  control  and 
monitor,  both  in  space  and  on  the  ground. 

• Provide  command  management  to  ensure  that  all  payload  and  subsystem 
commands  are  compatible  and  safe. 

• Provide  a capability  for  real-time  interaction  between  customer  and 
payload,  or  between  operator  and  subsystem. 

• Provide  onboard  resources  to  support  stored  command  sequences. 

Operations  Support 

• Provide  data  base  access  and  tools  to  support  mission  planning  and 
scheduling . 

• Support  integrated  operations  planning,  scheduling,  and  resource 
allocation. 

• Provide  users  with  visibility  into  future  plans,  schedules,  and  resource 
availability . 

• Support  fault  detection,  isolation,  recovery,  and  repair  for  subsystems 
and  payload. 

• Monitor  payload  and  subsystem  usage  of  Space  Station  resources.  Support 
appropriate  responses  to  resource  usage  deviations. 

• Provide  resource  utilization  history  reports. 

• Provide  payload  and  subsystem  event  history  reports. 

Testing,  Simulation,  and  Training  Support 

• Provide  hardware  and  software  interface  verification  tools. 

• Provide  a remotely-accessible  real-time  simulation  of  SSDS  software 
interfaces . 

• Provide  simulation  and  facilities  to  support  customer  and  operator 
training . 

• Provide  tools  to  support  development  of  software  and  procedures. 
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SSDS 


DATA  FLOW 


CUSTOMER 


Key  Function* 


■ Support  Payload 
Development 

■ Integrated  Mission 
Planning  and  Scheduling 

■ Integrated  Command 
Management 

■ Mission  Data  Capture, 
Transport,  and  Level  0 
or  1A  Processing 

■ Mission  Data  Archiving 
(Limited) 

■ Ancillary  Data  Collection, 
Processing,  Archiving 

■ Distribution  Network 
Management 


Mission  Data 
Ancillary  Data 
Operations  Data 
Planning  Data 


Utilization  Data  N 
Simulation  Models 
Payload  Status 
Quick-Look  Data  > 


■ Plans/Schedules 

■ Resource  Requests 

■ Payload  Commands  and  Data 

■ Database  Queries 


Includes: 

■ Onboard  Customer  Crew 
and  Operators 

■ Customers  Located  at 
Their  Own  Facilities 

■ Customers  Located  at 
Regional  Data  Centers 


Figure  3-3.  SSDS  External  Interface  With  Customers 


Key  Functions: 


Integrated  Command 
Management 

Ancillary  Data  Collection, 
Processing,  Distribution, 
and  Archiving 

Mission  Data  Captive, 
Transport,  and  Level  0 or 
1A  Processing 

Man-Machine  Interface 
Distribution  Network 
Management 


■ Commands  and  Data 
a Ancillary  Data 
a Resource  Status 


a Resource  Requests 
a Mission  Data 
a Engineering  Data 
a Database  Queries 


Includes: 


a Constellation  Interface 
a Orbital  Maneuvering 
Vehicle  Communication 
Interface 

a OMV  Berth  (Umbilical) 
a Orbital  Transfer  Vehicle 
Communication  Interface 
a Polar  Orbiting  Platform 
and  Co-Orbiting  Platform 
a Space  Station  Attached 
Payloads 


Figure  3-4.  SSDS  External  Interface  With  Payloads 


and  polar-orbiting  platforms.  Operational  analyses  led  to  the  identification 
of  a complete  set  of  elements  that  constituted  the  SSIS.  This  set  of  elements 
is  shown  in  Table  3.3-1  and  includes  the  basic  ground  system  elements  required 
for  mission  control  and  for  customer  data  handling  and  delivery. 
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SSDS 


DATA  FLOW 


OPERATOR 


Key  Functions: 


■ Provide  Man-Machine 
Interface 

■ Provide  Planning/ 
Scheduling  Support 

a Provide  Mission  and 
System  Status  Reports 

■ Maintain  Online  Database 
a Maintain  Engineering  Data 

Archive 

a Provide  Data  Transport 
Service 


Subsystem  Status 
Missions  Status 
Operations  Data 
Plans  and  Schedules 


■ Plans/Schedules  Updates 

■ Subsystem  Commands 

■ Resource  Requests 

■ Database  Queries 


Includes: 

a Space  Station  Core 
Operators 
a Onboard  Crew 
a EVA  Crew 
a Logistics  Operators 
a Regional  Data  Center 
Operators 

a Training  Instructors 


Figure  3-5.  SSDS  External  Interface  With  Operators 


GENERIC 

SSDS  DATA  FLOW  SENSORS  AND  EFFECTORS 


Figure  3-6.  SSDS  External  Interface  With  Subsystem  Sensors  and  Effectors 

A set  of  criteria  was  developed  to  sort  the  SSIS  elements  into  two  categories; 
(1)  within  the  SSDS  and  (2)  external  to  the  SSDS.  These  criteria  are 
summarized  as  follows: 

• Elements  that  provide  data  services  for  core  subsystems  or  that 

provide  "standard11  (no  cost)  data  services  to  customers  are  in  the 
SSDS.  Additional  "standard"  customers  services,  such  as  long-term 
archiving,  will  be  available  at  additional  costs.  These  additional 
services  are  not  in  the  SSDS. 


Key  Functions: 

■ Integrate  Command 
Management 

■ Provide  Man-Machine 
interface 

■ Manage  Downlink  Data 

■ Provide  Data  Transport 
Service 

■ Provide  Online  Database 

■ Provide  Engineering  Data 
Archive 
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SSDS 


DATA  FLOW 


INSTITUTIONAL 

SERVICE 


Key  Functions: 

■ Forecast  Service 
Requirements 

■ Generate  Service  Requests 

■ Provide  SSPE  Status 


Plans  and  Schedules 
Service  Requests 
Mission  Data 
Operational  Data 
SSP  System  Status 


Plans  and  Schedules 
Service  Request  Response 
Institutional  System  Status 
Mission  Data 
Operational  Data 


Includes: 

■ Tracking  and  Data 
Relay  Satellite  System 

■ Technical  and 
Management  Information 
System 

■ National  Space 
Transportation  System 

■ North  American  Air 
Defense  Command 

■ Network  Control  Center 


Figure  3-7.  SSDS  External  Interface  With  Institutional  Services 


• Elements  that  provide  data  services  that  are  unique  to  a particular 
customer  or  payload  are  not  in  the  SSDS. 

• Elements  that  are  multi-program  institutional  services,  such  as 
TDRSS,  are  not  in  the  SSDS. 

Using  these  criteria,  the  SSDS  elements  were  identified  (Table  3.3-2).  Each 
element  and  its  general  role  in  the  SSDS  is  discussed  below.  For  the  purpose 
of  developing  a "strawman"  system  definition,  locations  have  been  assumed  for 
these  elements. 

• The  Space  Station  - The  Space  Station  node  serves  as  a communications 
concentration  point  for  multiple  payloads,  core  subsystems,  and  other 
identified  elements.  These  include  the  OMV,  OTV,  free  fliers;  with 
options  for  STS  and  the  COP.  The  Space  Station  receives  data  from 
the  payloads  and  constellation  elements,  and  relays  the  data  to  the 
gorund,  together  with  core  systems  data.  The  Space  Station  routes 
the  commands  and  data  for  payloads,  core  systems,  and  other  SSPE's. 
The  Space  Station  Network  must  support  real-time  transmission  of 
operating  data  and  commands,  near  real-time  transmission  of 
quick-look  data,  and  delayed  transmission  of  bulk  commands  and  data. 
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Table  3.3-1  SSIS  Elements 


Space  Station  (SS) 

Polar  Orbiting  Platform(s)  (POP) 

Co-Orbiting  Platform(s)  (COP) 

Data  Handling  Center  (DHC) 

Space  Station  Operations  Control  Center  (SSOCC) 

POP  Operations  Control  Center  (POPOCC) 

COP  Operations  Control  Center  (COPOCC) 

Payload  Operations  Control  Center(s)  (POCC) 

Regional  Data  Center(s)  (RDC) 

Level  0 Processing  Facility  (LZPF) 

Ground  Services  Center  (GSC) 

Engineering  Data  Center  (EDC) 

Development,  Simulation,  Integration,  and  Training  (DSIT) 
Global  Positioning  System  (GPS) 

Free-Flyer(s)  (FF) 

Tracking  and  Data  Relay  Satellite  System  (TDRSS) 

Orbital  Maneuvering  Vehicle  (OMV) 

Orbit  Transfer  Vehicle  (OTV) 

Remote  Customer  Facilities 

NSTS  Orbiter 

Deep  Space  Network  (DSN) 

Technical  and  Management  Information  System  (TMIS) 

Launch  Integration  Facilities 
Contractor  Facilities 

Commercial  and  Institutional  Communications  Links 


Real-time  operations  of  the  payloads  require  limited  two-way  data 
relay,  including  audio  and  video  links. 

• Polar  Orbiting  Platform(s)  - The  POP  is  a polar  platform  in 

sun-synchronous  orbit  which  will  be  used  primarily  for  earth  and 
atmospheric  observation.  POP  has  no  interaction  with  the  Space 
Station  on  orbit,  but  will  share  some  ground  data  handling  facilities. 
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Table  3.3-2  SSDS  Elements 


Space  Station  (SS) 

Polar  Orbiting  Platform(s)  (POP) 

Co-Orbiting  Platform(s)  (COP) 

Data  Handling  Center  (DHC) 

Level  0 Processing  Facilities  (LZPF) 

Space  Station  Operations  Control  Center  (SSOCC) 

POP  Control  Center  (POPCC) 

COP  Control  Center  (COPCC) 

Payload  Operations  Control  Center(s)  (POCC) 

Engineering  Data  Center  (EDC) 

Development,  Simulation,  Integration,  and  Training  (DSIT) 
Ground  Services  Center  (GSC) 


The  Space  Station  Network  must  support  real-time  transmission  of 
operations  data  and  commands  for  the  POP  payloads  as  well  as  near 
real-time  transmission  of  quicklook  science  data  and  delayed 
transmission  of  stored  commands  and  data.  Based  on  the  mission 
model,  it  is  assumed  that  there  will  be  two  POP's  at  IOC,  three  at 
growth. 

Co— Orbiting  Platform(s)  — It  is  assumed  that  if  the  COP  maintains 
continuous  line-of-sight  with  the  Space  Station,  the  station  can  be 
used  as  a communications  relay  node.  Options  also  exist  for  a direct 
COP  to  TDRSS  link.  It  is  assumed  that  the  direct  TDRSS  link  will  be 
used  if  the  COP  is  not  in  continuous  line-of-sight  with  the  Space 
Station.  The  space  station  network  must  support  real-time 
transmission  of  operations  data  and  commands  for  the  COP  payloads  as 
well  as  near  real-time  transmission  of  quicklook  science  data  and 
delayed  transmission  of  stored  commands  and  data. 

Data  Handling  Center  — The  Data  Handling  Center  receives,  buffers  and 
retransmits  uplink  and  downlink  data.  High  speed  downlink  data  is 
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routed  based  on  predetermined  schedules,  low  speed  downlink  data  is 
routed  on  the  basis  of  information  which  is  contained  in  the  CCSDS 
telemetry  packet  header.  The  DHC  is  located  at  White  Sands. 

t 

• Space  Station  Operations  Control  Center  (SSOCC)  — The  SSOCC  is 
responsible  for  ground  support  of  the  Space  Station  operations  and 
control.  The  SSOCC  is  located  at  JSC. 

• POP  Operations  Control  Center  (POPOCC)  - The  POP  Operations  Control 
Center  is  responsible  for  ground  support  of  the  platform  operations 
and  control.  It  is  assumed  that  there  will  be  one  POPOCC  for  each 
POP.  The  POPOCC  is  located  at  GSFC. 

• COP  Operations  Control  Center  (COPOCC)  - The  COP  Operations  Control 
Center  is  responsible  for  the  ground  support  of  the  platform 
operations  and  control.  The  COPOCC  is  located  at  GSFC. 

• Payload  Operations  Control  Centers  (POCC's)  — The  POCC 1 s are 
responsible  for  the  ground  support  of  payload  operations  and 
control.  This  will  include  interactive  real-time  commanding  and 
quick-look  analysis  of  science  data.  The  POCC's  will  receive  a 
select  subset  of  core  ancillary  data  and  will  coordinate  operations 
with  the  related  Space  Station  or  platform  control  center.  It  is 
assumed  that  there  will  be  multiple  POCC's.  The  POCCs  are 
distributed  among  NASA  centers,  RDCs  and  customer  sites. 

• Level  0 Processing  Facilities  - Level  0 Processing  Facilities  (LZPFs) 
functions  are  standard  interfaces  (which  are  basically  the  same  as 
for  a POCC)  and  Level  0 Processing.  High  rate  LZPFs  are  co-located 
with  ROCs  at  GSFC,  JPL,  and  LARC.  A low  rate  LZPF  is  centralized  at 
GSFC  to  serve  the  other  RDCs  and  customers.  High  rate  LZPFs  are 
co-located  with  RDCs  at  GSFC,  JPL  and  LARC.  A low  rate  LZPF  is 
centralized  at  GSFC. 

• Ground  Services  Center  - The  Ground  Srvices  Center  (GSC)  provides 
communications  and  common  resource  coordination  for  the  ground 
system.  It  serves  to  coordinate  the  scheduling  of  the  communication 
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and  ground  facility  resources  shared  among  the  Space  Station,  COP, 
and  POP  operations  control  centers.  These  shared  facilities  include 
the  Data  Handing  Center,  and  the  Level  0 Processing  Facilities.  The 
GSC  also  collects  status  information  from  these  facilities  (outages, 
data  quality  monitoring,  etc)  and  prepares  reports  of  this 
information  to  both  customers  and  the  Global  System  Manager  at  the 
OCCs . The  GSC  also  performs  SSIS  functions  involving  the  collection 
of  usage  information  from  the  ground  elements  used  by  customers  and 
the  processing  of  customer  bills.  The  GSC  is  located  at  GSFC. 

• Engineering  Data  Center  - The  Engineering  Data  Center  provides 
archival  storage  of  Space  Station  engineering  data.  This  center  will 
support  program  and  customer  requests  for  Space  Station  historical 
data.  One  Engineering  Data  Center  is  co-located  with  the  SSOCC  (at 
JSC)  and  a second  EDC  is  co-located  with  the  POP  & COP  OCCs  at  GSFC. 

• Development.  Simulation,  Integration  and  Training  - The  DSIT  will 
support  the  development  and  integration  of  new  and  modified  software, 
software  uplink,  integration  of  customer  payloads,  end-to-end 
communications  checkout,  use  of  flight  equipment  in  lieu  of  GSE,  crew 
training,  and  construction  of  simulation  models  for  use  at  remote 
sites.  The  SSE,  a key  part  of  this  capability,  is  described  in 
Section  8.  The  DSIT  functions  will  be  distributed  throughout  the 
ground  system;  elements  of  the  DSIT  will  appear  at  each  Control 
Center,  LZPF,  RDC  and  facilities  that  involve  software  development 
and  simulations. 

• Regional  Data  Centers  - Regional  Data  Centers  are  SSIS  elements  that 
fall  outside  the  SSDS  boundaries,  but  their  location  affects  the  SSDS 
architecture.  Their  basic  function,  as  assumed  in  this  study,  is  the 
support  of  a single  scientific  discipline  or  group  of  related 
disciplines  (at  each  RDC).  The  RDCs  receive,  analyze  (processing 
above  Level  0)  and  archive  data  from  many  sources,  including  space 
entities  as  well  as  non-space  sources.  It  is  assumed  that  the  RDCs 
are  mapped  into  the  following  disciplines; 
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RDC  1 - Astrophysics 
RDC  2 - Solar 

RDC  3 - Earth  and  Planetary 

RDC  4 - Life  Sciences 

RDC  5 - Environmental 

RDC  6 - Materials  Processing 

It  is  assumed  that  RDCs  will  be  established  at  GSFC,  JPL,  LARC,  JSC,  MSEC 
and  customer  sites. 

3 . 4 Functional  Allocation  to  Elements 

The  requirements  definition  task  of  the  SSDS  study  derived  and  validated  an 
extensive  set  of  functions  that  define  the  tasks  that  the  SSDS  needs  to 
perform.  The  functions  were  identified  by  examination  of  mission 
requirements , operational  scenarios,  and  subsystem  interfaces,  and  by 
decomposition  of  high-level  functions  into  lower  and  lower  levels  through 
structured  systems  analysis.  The  top  two  levels  of  the  function  set  are  shown 
in  Figure  3-8.  The  complete  set  includes  over  300  functions  and  is  described 
in  the  task  1 report  (requirements  definition). 

The  implementation  of  the  functions  into  an  SSDS  architecture  was  approached 
in  an  incremental  manner  as  illustrated  in  Figure  3-9,  with  the  first 
allocation  defining  the  space  versus  ground  functions,  the  next  step 
allocating  functions  to  elements  (see  paragraph  3.3),  and  finally,  an 
allocation  to  SSDS  nodes  within  the  elements.  The  key  trade  studies  that 
supported  these  allocation  steps  are  shown  in  Figure  3-9.  These  trade  study 
results  are  documented  in  the  Task  3 report. 

The  space/ground  function  allocation  is  intimately  related  to  the  degree  of 
space  autonomy  and  to  the  degree  of  automation  of  in-space  functions.  The 
degree  of  automation,  whether  AI  or  conventional,  has  a strong  bearing  on  the 
degree  of  space  autonomy  that  is  achievable  since  on-orbit  crew  time  is  a 
scarce  resource.  Consequently,  there  will  be  a strong  motive  to  assign 
functions  that  cannot  be  readily  automated  to  the  ground  segment. 
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SSDS  FUNCTIONS 
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NOTE:  Requirements  listed  at  a higher  level  are  generally  applicable  to  all  lower  level  functions. 


Requirements 


Space/ 

Ground 

Allocation 


Level  of 
Distribution 
and  Design 
Detail 


Allocation  to  Space/Ground 
Link  Characteristics 

Network  Topology 

■ Allocation  to 
Network  Nodes 

Interconnection 
Characteristics 


Local 

Area  (Node) 
Architectures 


Allocation  to 
Computational/ 
Storage  Resources 


Key  Trade  Studies 

■ Automation 

■ Autonomy 


■ End-to-End  Networking 

■ Standardization 

■ Distributed  DBMS 

■ Space  Communications 


■ Local  Area  Networks 

■ BIU 

■ Network  Media 

■ Fault  Tolerance 

■ 


Figure  3*9.  Incremental  Design  Approach 


Our  approach  has  been  to  (1)  perform  a space/ground  function  allocation  based 
on  a set  of  coordination  criteria,  (2)  categorize  each  function  implementation 
as  automated,  interactive,  or  manual  based  primarily  on  crew  impact,  response 
time  requirements,  and  automation  feasibility  and  cost.  The  ATAC  draft  report 
provided  guidance  for  this  decision.  The  Space  Autonomy/Function  Automation 
trade  study  in  the  Task  3 report  shows  the  current  allocation  of  functions  to 
the  space  and  ground  segments  and  the  level— of-automation  category  for  each. 
Table  3.4-1  shows  the  criteria  used  in  developing  this  allocation. 

Within  each  of  the  two  major  SSDS  segments  (space  and  ground),  functions  have 
been  allocated  to  the  next  lower  level.  Ground  functions  have  been  allocated 
to  the  various  ground  elements.  The  results  of  this  allocation  are  discussed 
in  Section  7.  Onboard  functions  have  been  allocated  to  subsystems  and 
modules.  This  allocation  is  discussed  in  Section  6.  A current  function 
allocation  matrix  is  included  in  Appendix  H. 

The  primary  partitioning  criteria  that  guided  this  network  allocation  process 
is  shown  in  Table  3.4-2.  The  applicability  of  the  criteria  to  ground  element 
allocation  and  onboard  subsystem  allocations  are  identified.  The  resulting 
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Table  3.4-1 


Criteria  for  Space/Ground  Allocation 
and  Function  Automation 

Criteria 

Comment 

Criticality 

What  is  the  allowable  restoration  time  for 
the  function  after  a failure? 

Impact 

What  is  the  potential  impact  of  a failure  of 
this  function  on  crew,  systems,  or  missions? 

Co-location 

Should  the  function  be  co-located  with  its 
input  data  source? 

Space/Ground  Link 

Availability 

Is  the  availability/reliability  of  the 
communications  link  a determinant  in  the 
function  location? 

Function  Autonomy 

Does  the  function  have  significant  I/O 
traffic  with  other  functions? 

Response  Time 

Is  the  communication  delay  significant  to 
performance  of  the  function? 

Space/Ground  Link 

Bandwidth 

Is  the  finite  TDRSS  bandwidth  a significant 
factor? 

allocations  need  to  be  periodically  reviewed  and  updated  as  the  system 
definition  progresses  to  account  for  changes  in  program  priorities  and  goals 
and  to  incorporate  the  improved  level  of  detail  in  the  SSDS  definition. 

3 • 5 SSDS  Topology/Connectivity 

The  topology  of  the  SSDS  defines  the  connections  (data  paths)  between  the 
elements  of  the  SSDS.  This  section  provides  an  overview  of  the  top-level  SSDS 
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Table  3.4-2 
Partitioning  Criteria 


Ground  Onboard 


1.  Partition  so  that  stand-alone  development  X X 

of  elements/subsystems  is  possible. 

2.  Partition  to  minimize  interface  complexity.  X X 

3.  Partition  so  that  interfaces  are  testable.  X X 

4.  Partition  so  that  critical  and  non-critical  X X 

functions  are  separated. 

5.  Partition  to  support  time— phased  buildup  X 

to  IOC. 

6.  Partition  to  efficiently  use  power,  weight,  X 

volume,  etc. 


7.  Partition  so  that  response  time  require-  X X 

ments  can  be  met. 

8.  Partition  so  that  resources  and  data  can  X X 

be  efficiently  shared. 

9.  Partition  to  facilitate  system  growth  and  X X 

technology  insertion. 


end-to-end  topology  and  of  the  Space  Station  onboard  SSDS  topology.  The 
topology  selection  has  been  driven  primarily  by  user  data  traffic  needs  and 
analysis  and  growth  considerations  but  is  also  affected  by  institutional 
resources  (e.g.,  TDRSS),  and  operational  flexibility  considerations.  For 
instance,  we  have  assumed  that  the  Space  Station  will  be  capable  of  acting  as 
a communication  node  for  the  COP  to  allow  efficient  use  of  TDRSS,  but  we  have 
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included  in  our  topology  a direct  COP-to-TDRSS  link  for  added  operational 
flexibility  and  for  contingency  modes. 

The  elements  of  the  SSDS  were  identified  and  discussed  in  paragraph  3.3. 

Figure  3-10  shows  the  top-level  SSDS  topology  that  interconnects  these 
elements.  In  general,  these  connections  are  all  duplex  and  are  implemented  in 
a range  of  capacities  and  forms  to  best  match  the  system  needs  with 
capabilities.  While  the  topology  shows  all  space  segment-to-ground  segment 
traffic  passing  through  TDRSS,  a direct  channel  between  a space  element  and  a 
customer  facility  is  not  precluded  (outside  of  SSDS).  In  addition,  system 
failure  tolerance  needs  may  dictate  a direct-to -ground  link  as  a backup  to 
TDRSS  for  operational,  rather  than  mission-related,  communications.  Figure 
3-10a  illustrates  the  multiplicity  of  SSDS  elements  and  identifies  those  data 
paths  that  are  expected  to  be  design  drivers  due  to  their  traffic  levels. 
Figure  3-10b  describes  the  supporting  data  and  assumptions  used  to  derive 
these  network  data  rate  characteristics . 


Figure  3-10.  Overall  SSDS  Topology 
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Data  rate  entry  Data  rate 


— All  Rates  in  Mbps  — 
Source  or  makeup 


Space  Station  peak  300  Remote  Sensing  Test 


POP  peak 


300  SAR  on  POP-2 


Space  Station  average 


Remote  sensing  test 
Solar  terrestrial  obs. 
Pinhole  Occultor 
Misc  payloads 
Payload  video 
Core  data 
Core  audio/video 


Comments 


• Other  Ku-band  data  recorded  during 
operation 

• Other  data  recorded  or  transmitted  in 
S-band 

• POP-1  total  is  393  Mbps,  recording 
assumed  for  excess  over  Ku  capacity 

• Record  capability  required  for 
exclusion  zone  adequate  to  buffer 
POP-1 

• Consider  providing  600  Mbps 
capability  to  improve  SAR  resolution 
by  buffering  or  use  of  both  TDRS  SA 
channels 

• TDMX  2542  corrected  to  10kbps 

• Payload  video  38  hr/day  lab  coverage 
at  1 frame/sec,  plus  7 hr/day  at 
4.5Mbps  NTSC 

• 2 channels  surveillance  video  at 
4.5Mbps  plus  6 hr/day  at  22Mbps 


COP  average 
POP-1  average 


POP-2  average 


1Mbps  payload,  0.2  core 

Stereo  I.S  - 54.2 

High  res  I.S.  -21.7 

Misc  - 3.7 

Core  data  - 0.2 

SAR  - 16.25 

Misc  - 2.85 

Core  data  - 0.2 


Duty  cycles  are  expected  to  be 
reduced  to  less  than  half  for  high-rate 
missions 


Figure  3-10b.  Supporting  Data  for  SSKS  Data  Network  Rates  — IOC 
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The  ground  segment  topology  allows  the  Data  Handling  Center  to  sort  and 
distribute  downlink  data  directly  to  users  and  to  collect  uplink  data  from 
users  for  routing  to  space  elements.  Many  element-to-element  links  are 
provided  within  the  ground  segment  to  handle  not  only  mission  data  traffic  but 
system  management  and  administrative  traffic. 

Growth  can  be  accommodated  in  the  ground  segment  topology  by  virtue  of  the 
mesh-like  connectivity.  This  allows  routing  flexibility  as  the  data  traffic 
increases.  TDRSS  enhancement  (i.e.,  TDAS)  that  provide  direct  broadcast  of 
space  data  to  regional  sites  will  be  readily  accommodated  by  this  topology  arid 
by  the  distributed  nature  of  the  user  data  processing  in  the  SSDS  ground 
segment . 

The  single  access  channel  connectivity  is  shown  in  Figure  3-11.  This 
connectivity  assumes  that  a second  TDRSS  ground  terminal  is  available.  Three 
TOR  satellites  are  shown  as  an  example  of  potential  TDRSS  space  segment 
configurations.  Either  1,  1,  or  3 of  these  SA  channels  may  be  carrying  SSDS 


SS/POP1/POP2 

DATA 


SS/POP1/POP2 

DATA 


1 SA  Ch/SSPE  Max, 
Limited  By  Line-of-Sight 

SSDS  Sensitivity  to  Number  of 
SA  Channels  (1,  2 or  3) 

■ Onboard/Ground  Tradeoffs 

Mass  Storage  Trade  Study 
(1  SA  Worst  Case  for 
Onboard  Buffer) 

Network  Topology  Trade 
Study  (3  SA  Worst  Case  Peak 
Rate) 

Signal  SA  Possible 
(Task  1 Assumption) 

• Extensive  Onboard  Buffering 

• Optimal  Scheduling 

• Core  Video  Uncertainties 
Recommend  Minimum  of  2 SA 

Reduce  Onboard  Buffering 
Cost 

• Robust  Margin 

• Schedule  Flexibility 


Figure  3-11.  SA  Channel  Connectivity 
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traffic  at  a given  time,  depending  on  the  TDRSS  SA  allocation.  We  have 
assumed  that  either  TDRSS  ground  terminal  may  be  acquiring  data  from  any  TDR 
satellite  and  that,  therefore,  SSDS  SA  traffic  can  come  to  the  DHC  from  either 
ground  terminal. 

The  space  station  on-board  SSDS  segment  Topology  is  shown  in  Figure  3-12. 

This  topology,  which  is  also  applicable  to  the  platforms,  consists  of  a group 


3-38 


of  interconnected,  dual  redundant,  token-ring  busses,  with  major  partitions 
between  payload  (customer)  networks  and  core  networks. 

A token  ring  will  be  needed  in  each  module,  at  each  end  of  the  power  tower 
configuration  and  on  the  solar  array  truss.  It  is  desirable  to  separate  the 
core  data  traffic  from  the  payload  traffic  whose  growth  is  difficult  to 
predict.  This  will  maximize  the  possibility  of  using  the  core  network  for  a 
majority  of  subsystem  data  transmission  (i.e.,  minimize  dedicated  subsystem 
local  busses  by  providing  a core  network  with  predictable  and  acceptable 
transmission  delays  to  sensors  and  effectors). 


This  configuration  will  provide: 


1)  Maintainability  by  allowing  network  repair  and  checkout  at  the 
concentrator . 

2)  Ease  of  connectivity  during  build-up. 

3)  Token  ring  allows  for  prioritization  of  token  to  support  real-time 
control  application. 

4)  Token  ring  performance  is  superior  to  CSMA/CD  with  high  traffic  loads 
(and  superior  to  '‘voting  arbitration"  methods). 

5)  Emerging  ANSI  standards  (X3T9.5)  to  promote  growth  for  fiber  optic 
media. 


Safe  haven  requirements  can  be  met  by  having  separate  token  rings  in  each 
module.  The  onboard  topology  is  discussed  in  more  detail  in  Section  6. 

Detail  on  the  ground  network  topology  is  in  Section  7.  Trade  studies  leading 
to  the  topology  selections  are  documented  in  the  Task  3 report. 


3 . 6 SSDS  Operational  Concepts  Overview 

A key  component  of  the  SSDS  architecture  definition  is  a description  of  how 
the  SSDS  operates  as  viewed  by  the  user.  This  section  provides  an  overview  of 
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some  of  the  key  SSDS  operational  concepts,  including  mission  planning  and 
scheduling,  payload  control,  customer  data  handling,  and  software 
development.  More  detail  on  these  operational  concepts,  and  discussion  of 
additional  concepts  may  be  found  in  sections  4,  6,  7,  and  8. 


3.6.1  Mission  planning  and  scheduling.  The  planning  and  scheduling  process 
is  illustrated  in  Figure  3-13.  It  begins  with  identification  of  significant 
milestones  in  the  SSP,  herein  called  Major  Events.  Major  Events,  by  their 
nature,  will  have  an  impact  on  the  entire  scope  of  spacecraft  and  mission 
operations.  These  events  include  visits  by  the  NSTS  orbiter,  changes  of 
payload  compliment,  changes  of  spacecraft  equipment,  and,  for  the  Space 
Station,  major  operations  such  as  OMV  and  OTV  launches  and  satellite  servicing. 
The  Major  Events  form  a framework  into  which  the  normal  operations  of  mission 
payloads  and  core  systems  must  fit.  Long  term  planning  will  be  used  to 
apportion  operating  time  and  critical  resources  among  customer  and  space  craft 
objectives.  The  major  events  and  apportioned  resources  become  the  SSP  Master 
Plan,  which  is  developed  and  maintained  by  the  SSDS. 


Figure  3-13.  SSP  Mission  Planning  and  Scheduling 
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A Short  Term  Schedule  is  developed  beginning  approximately  two  weeks  in 
advance  of  the  time  of  actual  operation.  Specific  customer  mission 
requirements , payload  and  core  system  maintenance  and  servicing  requirements, 
and  major  events  are  input,  together  with  anticipated  spacecraft  capability. 
The  scheduling  function  seeks  an  arrangement  which  maximizes  the  value  of 
payload  output  within  expected  resource  limitations.  This  process  proceeds  in 
two  hierarchial  steps: 

1)  Communication  Link  Scheduling  - The  TDRSS  and  Space  Station  Data 
network  links  are  shared  among  the  Space  Station  and  platform 
systems.  The  first  step  is  to  schedule  use  of  these  links.  To 
minimize  onboard  storage  for  the  very  high  data  rate  missions,  bent 
pipe  relay  is  preferred.  The  polar  platforms  will  not  be  able  to 
utilize  this  communications  mode  in  the  zone  of  exclusion,  but  will 
still  benefit  from  its  use  elsewhere  by  reducing  onboard  buffer 
requirements . Hence,  priority  allocations  are  made  to  the  high  rate 
missions,  consistent  with  their  desired  operating  times  and 
availability  of  appropriate  targets  and  data  network  links. 

The  next  priority  is  given  to  real  time  and  quick  look  requirements 
for  interactive  control.  Real  time  and  quick  look  are  distinguished 
by  an  identified  need  for  communication  between  space  and  ground 
measured  in  seconds,  as  opposed  to  tens  of  minutes.  The  later  should 
be  accommodated  in  normal,  bulk  transmissions.  Only  data  rates  above 
the  very  low  rates  accommodatable  within  a TDRS  MA  channel  are 
considered  in  this  grouping. 

The  final  grouping  includes  bulk  space-ground  communication.  The 
communications  are  coordinated  with  the  NCC  and  NASCOM  from  a single 
point  of  contact  within  the  SSDS. 

2)  Spacecraft  and  Facility  Scheduling  - With  the  communications  schedule 
established  as  the  only  regularly  occuring,  program  wide  interaction 
among  SSPEs,  each  facility  and  spacecraft  can  undertake  its  own 
internal  scheduling.  It  is  noted  that  coordinated  operation  of 
payloads  between  spacecraft  may  be  required  by  customers.  However, 
this  operation  should  be  accommodated  in  the  communications  schedule 
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and  within  the  schedules  of  the  individual  spacecraft.  The 
communications  schedule  provides  for  the  primary  coordinated  activity 
among  the  SSPGs. 

Developing  the  short  term  schedule  is  expected  to  involve  interaction  and 
negotiation  among  customers.  This  may  be  especially  true  for  earth 
observations.  The  customers  will  select  targets  and  instruments  to  be  used, 
and  the  control  center  developing  the  schedule  will  be  able  to  determine  when 
the  targets  will  be  observable.  The  schedule  function  will  attempt  to  balance 
resources  available  with  observation  opportunities  to  maximize  the  total  value 
of  payload  output.  Most  of  the  Space  Station  payloads  will  be  competing  for 
electric  power  and  crew  time.  The  scheduler  function  will  attempt  to  allocate 
these  resources  in  a similar  optimum  manner. 

A very  valuable  adjunct  to  preparing  the  short  term  schedule  is  a set  of 
prestored  templates  of  recurring  operations.  These  templates  cover  at  least 
the  use  profiles  for  power,  crew  time  and  communications.  Other  resources  may 
be  included  if  it  is  determined  that  these  resources  are  important  to 
scheduling.  However,  details  of  the  process  which  do  not  affect  resources  are 
not  included. 

The  templates  for  requested  operations  are  assembled  according  to  timing,  crew 
preference,  resource  demand,  and  resource  availability  considerations. 
Negotiations  among  customers  and  operators  are  conducted  to  resolve 

difficulties,  including  potential  problems  of  safety  and  interference  among 
operations . 

The  scheduling  and  negotiation  process  is  continued  until  a best  obtainable 
schedule  is  developed.  However,  the  schedule  is  held  open  until  the  last  few 
hours  (or  less)  to  accommodate  targets  of  opportunity  and  other  unforseen 
events.  The  dynamic  result  is  the  short  term  schedule.  It  should  be  noted 
that  these  scheduling/negotiation  functions  are  provided  to  the  customer  as  an 
optional  service  to  enhance  the  probability  of  having  access  to  available 
resources  at  the  time  of  need. 
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An  Operating  Events  schedule  is  developed  from  the  short  term  schedule, 
containing  the  actual  commands  required  to  implement  the  short  term  schedule. 
The  origin  of  these  commands  and  their  management  is  discussed  under  Section 
3.6.2. 

3.6.2  Command  management.  The  command  management  process  and  the  planning 
and  scheduling  process  are  mutually  complementary.  Planning  and  scheduling 
provides  for  the  efficient  use  of  critical  resources  and  reserves  operating 
envelopes  for  the  payload  and  core  operations.  Command  management  provides 
the  commands  to  implement  the  operating  schedule.  Its  objectives  are  to 
ensure  that  the  Space  Station  system  is  responsive  to  user  commands  and  to 
prevent  damage  to  the  Space  Station  systems  and  payloads  and  to  prevent  crew 
injury  as  a result  of  those  commands.  Our  operational  concept  meets  these 
objectives  by  incorporating  the  following  features: 

1.  Payload  and  core  system  operations  are  classified  by  a joint 
NASA/customer  review  as: 

• Restricted  - Those  which  pose  a potential  hazard  to  the  Space 
Station  or  crew. 

• Constrained  - Those  which  may  interfere  with  other  payloads  or 
core  systems. 

• Non-restricted  — all  others. 

2.  Commands  implementing  these  operations  assume  the  classification  of 
the  operation. 

3.  Non-restricted  commands  may  be  sent  directly  to  any  payloads  or  core 
subsystem  (or  originated  by  the  payloads  or  subsystems).  The  SSDS 
responsibility  will  be  limited  to  authenticating  the  sender  and 

add  re  s s . 

4.  Restricted  and  constrained  commands  must  be  determined  by  the  SSDS  to 
be  executable  at  the  time  of  execution.  The  SSDS  may  provide  user 
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friendly  aids  to  the  customer  and  operator  to  assist  in  clearing 
commands  determined  to  be  not  executable  under  conditions  forecast  at 
the  planned  time  of  execution, 

5.  The  SSDS  will  not  test  the  customers  commands  for  implementability  or 
potential  damage  to  the  payload.  These  responsibilities  remain  with 
the  customer. 

Figure  3-14  illustrates  this  command  management  concept.  The  SSDS  is 
responsible  for  authentication  of  the  customer  or  operator  issuing  a command 
and  the  payload  or  core  system  addressed.  All  non-restricted  commands  are,  by 
definition,  executable  at  any  time.  These  are  passed  directly  to  their 
destination.  Restricted  and  constrained  commands  are  conditionally 
executable.  When  the  planning  and  scheduling  process  has  been  used  as  an 
optional  service  to  create  the  necessary  conditions  for  a restricted  or 
constrained  command  to  be  safely  executed,  the  command  is  issued  at  its 
scheduled  time.  If  these  necessary  conditions  do  not  exist  or  are  not 
forecast  to  exist  at  the  scheduled  time,  the  command  is  judged  to  be  not 
executable.  The  scheduling  process  may  be  re-entered  to  determine  whether  the 
schedule  can  be  altered  to  accommodate  the  command.  If  so,  the  schedule  is 
changed  and  reissued  and  the  command  is  reclassified  to  executable.  The 
customer  or  operator  issuing  the  command  may  be  contacted  to  aid  in 
accommodating  the  requested  operation.  If  it  is  not  possible  to  accommodate 


Figure  3-14.  Command  Management  Concept 
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the  command,  the  originator  is  notified  and  supplied  the  reasons  for  the 
command  being  not  executable.  The  executability  of  these  commands  will  be 
subject  to  resouce  availability  and  constraint  conditions  at  the  time  of 
execution.  A "robust"  SSDS  design  will  help  to  maximize  the  probability  of 
unscheduled  command  execution.  However,  it  should  be  noted  that  some  key 
resources  are  not  contained  within  the  SSDS  (i.e.  power,  TDRSS,  etc.). 

3.6.3  Customer  data  handling.  A primary  responsibility  of  the  SSDS  toward 
Space  Station  customers  is  to  provide  a highly  reliable,  robust,  transparent 
data  transport  service.  The  SSDS  also  provides  data  processing,  data  storage, 
and  ancillary  data  services  for  customers.  The  architectural  features  that 
implement  these  services  effectively  and  efficiently  include  the  following: 

• Standard  data  communication  protocols  and  formats  based  on  the 
ISO/OSI  model  and  the  CCSDS  recommendations  for  payload  and  ancillary 
data  formatting  and  transport. 

• Onboard  buffering  of  payload  and  ancillary  data. 

• Limited  onboard  mass  data  storage  for  payload  data  bases  and  software. 

• Short-term  ground  storage  of  customer  data  to  facilitate  data 
delivery  and  assurance  of  satisfactory  quality.. 

• Network  control,  data  sorting,  data  routing,  data  time-ordering , and 
artifact  removal  services  as  necessary  to  make  the  overall  data 
transport  function  transparent  to  customers. 

• First-level  sorting  of  customer  data  at  White  Sands  for  separate 
transmission  to  discipline-oriented  RDC's. 

• Ancillary  data  provided  to  the  onboard  payloads  to  allow  merging  with 
payload  data  at  the  source. 

• Electronic  access  to  an  ancillary  data  base  that  will  be  maintained 
by  SSDS  at  the  EDC  and  spacecraft  control  locations.. 
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• Customer  data  privacy  and  customer  control  of  third-party  access  to 
customer  data.  The  SSDS  allows  customer  data  encryption,  as  long  as 
headers  are  readable,  to  permit  the  customer  to  provide  his  desired 
level  of  security. 


Customer  data  processing  (beyond  the  Level  0 processing  described  above)  may 
be  implemented  in  several  ways.  Onboard  payload  data  processing  may  be  done 
in  a payload-provided  processor  or  in  an  SSDS-provided  standard  data 
processor.  In  either  case  the  processor  has  access,  through  a standard 
interface,  to  the  onboard  LAN’s,  the  communication  gateways,  the  onboard  data 
base,  and  the  onboard  work  stations.  Ground  data  processing  beyond  Level  0 
may  be  provided  as  a service  by  NASA  (outside  of  SSDS)  or  may  be  done  by  the 
customer.  The  RDC's  and  POCC's  will  have  data  processing  resources  (CPU's, 
operating  systems,  peripherals,  etc.)  to  support  customer  data  processing. 

The  SSDS  data  archiving  is  limited  to  one  week  storage  after  receipt  of 
verification  of  acceptable  data  quality  from  the  customer.  Long  term 
archiving  for  up  to  two  years  is  an  SSIS  service  which  may  be  negotiated  with 
the  customer.  The  archival  services  will  generally  not  be  extended  to  "bent 
pipe"  relayed  data,  as  the  data  capture  function  is  bypassed  at  all 
intermediate  nodes.  If  exceptions  to  this  rule  are  to  be  negotiable, 
additional  high  rate  equipment  for  data  capture  will  be  required. 

The  SSDS  data  transport  service  is  symmetrical  in  the  sense  that  commands  may 
be  sent  from  ground  to  space  and  from  space  to  ground.  Data  may  likewise  be 
sent  in  either  direction.  For  commands,  the  SSDS  implements  the  CCSDS 
protocol  that  resends  the  command  if  a transmission  error  is  detected. 

3.6.4  SOFTWARE  SUPPORT  ENVIRONMENT  (SSE) 

The  purpose  of  the  SSE  is  to  provide  an  environment  to  support  the  development 
of  software  for  the  Space  Station.  The  SSE  is  a set  of  tools  which  are 
portable  and  will  be  made  available  for  subsystem  and  payload  developers.  The 
tools  included  in  the  SSE  will  not  dictate  a specific  methodology  or  set  of 
procedures.  The  users  will  be  able  to  define  their  procedures  (within  limits) 
and  utilize  subsets  of  the  tools  as  required  to  support  those  procedures. 
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The  primary  goals  of  the  SSE  are  to  reduce  the  life  cycle  cost  and  insure  the 

quality  of  all  software  produced  for  the  Space  Station.  This  includes  core, 

payload,  ground  support,  and  SSE  software.  This  will  be  accomplished  by  the 

achievement  of  the  following  subgoals: 

1.  Provide  a stable,  common  base  for  the  development  of  the  software. 

2.  Provide  integrated  support  of  the  entire  software  life  cycle,  from 
conceptual  definition  through  delivery,  including  configuration  management 
at  all  stages. 

3.  Provide  easily  attainable  status  at  many  levels  by  providing  tools  which 
facilitate  definition,  scheduling  and  tracking  of  intermediate  milestones. 

4.  Provide  state  of  the  art  tools  for  each  task  in  the  software  life  cycle  to 
increase  overall  productivity. 

5.  Provide  a common,  convenient  interface  for  each  of  the  tools  to  avoid  the 
necessity  of  learning  multiple  interfaces. 

6.  Provide  an  easy  way  to  expand  the  tool  set  in  order  to  add  new  tools. 

7.  Provide  a method  of  maintaining  multiple  versions  of  all  documentation 
such  that  it  is  available  on-line  or  it  can  be  printed. 

8.  Provide  tools  which  support  and  encourage  commonality  and  the  reuse  of 
existing  components. 

9.  Provide  sufficient  flexibility  within  the  configuration  management  and 
software  engineering  methodology  support  to  make  the  SSE  attractive  to 
payload  customers  as  well  as  satisfying  the  needs  of  core  software 
developers . 

10.  Provide  SSE  capabilities  such  that  support  provided  is  independent  of 
users  physical  location. 
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The  types  of  software  support  by  the  SSE  will  include: 


• Real  Time  Flight  Software 

• Ground  Command  and  Control  Software 

• Ground  Data  Processing  Software 

• Support  Software 

• Integration  and  Test  Software 

• Emulation  and  Model  Software 

• Customer  Application  Software 

The  SSE  will  be  used  by  development  groups  to  generate  software  elements,  and 
by  the  software  integration  site  to  combine  the  elements  into  integrated 
software  loads.  The  support  provided  to  each  development  user  group  will  be 
identical.  This  support  will  be  provided  in  a manner  which  will  allow  each 
group  to  develop  their  applications  as  autonomously  as  possible,  but  will 
encourage  communications  and  software  commonality  among  the  groups.  This  is 
depicted  in  Figure  3-15.  Each  function  in  the  figure  is  summarized  in  the 
following  paragraphs  and  is  described  in  more  detail  in  paragraph  8.2.  The 
support  for  the  integration  will  consist  of  many  of  the  same  functions  as 
provided  for  the  development  groups,  but  it  will  also  include  facilities  to 
integrate  the  software  produced  by  all  and  it  will  provide  more  extensive 
system/integration  test  facilities. 

A set  of  tools  will  be  provided  by  the  SSE  to  support  Configuration  Control 
and  to  support  management  in  user  activities  of  planning  and  resource 
allocation.  It  is  assumed  that  to  maintain  configuration  control  over  the 
Space  Station  software,  the  project  will  utilize  a series  of  NASA  and 
contractor  control  boards  (similar  to  what  has  been  used  in  previous  NASA 
projects)  and  an  automated  data  base  system  for  storing  and  enforcing 
decisions  made  by  the  boards. 

Requirements  Generation/Analysis,  using  tools  provided  by  the  SSE,  provides  a 
foundation  for  software  by  identifying  interface  details,  providing 
descriptions  of  functions,  determining  design  constraints,  and  defining 
software  validation  requirements . On  a project  as  large  and  complex  as  Space 
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Figure  3-15.  Services  Provided  by  the  SDE  for  the  Development  Function 


Station,  each  of  the  afore  mentioned  are  crucial  to  maintain  communication 
between  the  requirements  initiator  and  the  software  developer. 

Design  and  code  generation  is  the  process  by  which  programmers  create  new 
software  and  make  changes  to  previously-created  software.  Because  the  process 
is  a creative  one,  it  tends  to  rely  heavily  on  manual  inputs  made  by  skilled 
humans.  In  order  to  generate  software  for  the  Space  Station  in  the  most 
cost-effective  manner,  the  SSE  must  provide  tools  to  assist  the  human 
programmer  in  designing  and  coding  in  the  most  efficient  and  errorfree  manner 
possible.  See  Figure  8.2-6  for  a summary  of  the  process. 

The  System  Build  and  Integration  function  of  the  SSE  provides  the  tools 
necessary  for  orderly  and  controlled  collection  and  integration  of  software 
systems  (and  their  associated  documentation  and  data)  by  their  developers  and 
testers  and  for  controlled  delivery  of  those  systems  to  their  users. 

Testing  is  the  examination  of  program  execution  behavior.  Testing  of  the  Space 
Station  software  will  be  very  important  because  of  its  life/mission  critical 
nature.  Facilities  must  be  provided  in  the  SSE  for  testing  because  of  the 
inability  to  observe  the  software  in  actual  use  in  a safe  environment  (i.e.  on 
the  ground).  These  test  facilities  should  include  a variety  of  tools  that  will 
support  cost  effective  testing  of  the  core,  application  software,  and  payload 
software . 

The  tools  and  capabilities  provided  for  test  and  analysis  represent  the  full 
spectrum  of  test  facilities  for  the  project.  Subsets  may  be  defined  and  used 
to  support  various  levels  such  as  unit  testing,  performance  testing,  and 
independent  verification  and  validation. 

The  documentation  function  of  the  SSE  will  provide  online  documentation 
facilities  to  create  a minimum  paper  environment  with  hard  copying 
capability.  This  function  will  be  used  for  viewing  as  well  as  creating  the 
online  documents.  There  will  be  a capability  to  assign  access  levels  for 
security  of  nonpublic  documents.  Examples  of  document  types  are: 
requirements , user's  guides,  instruction  manuals,  test  specifications,  program 
test  reports,  software  build  reports,  status  reports,  and  working  papers. 
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Working  papers  are  lost,  historically,  in  most  long-lived  projects  as  the 
designers  move  on  to  newer  tasks.  The  documentation  capabilities  will  support 
the  archiving  of  background  information,  such  as  design  rationale  and 
justification,  etc. 

The  communication  function  will  provide  the  means  to  make  the  SSE  appear  as  a 
single  facility  to  each  user,  regardless  of  site  location.  It  will  enable  a 
user  to  send  and  receive  data,  e.g.,  documents,  messages,  or  software  to  other 
users  or  functions  of  the  SSE.  This  function  will  field  requests  from  other- 
functions  to  transfer  data  between  functions  and  to  users. 

The  software  on  the  Space  Station  will  be  required  to  interface  with  a vast 
number  of  hardware  components  (e.g.  IMUs,  rate  gyros,  etc.).  During  the  life 
time  of  the  station,  it  will  be  necessary  to  integrate,  test,  operate,  and 
replace  hardware  components.  Each  component  has  specific  characteristics 
which  must  be  provided  for  within  the  software.  Reconfiguration  data  is  that 
set  of  data  values  required  to  tailor  the  application  software  and  user 
interface  language  interface  environments  to  be  compatible  with  a specific 
hardware  configuration.  The  process  of  managing  the  reconf iguration  data  and 
incorporating  updates  into  the  target  system  (e.g.  onboard  DMS,  integration 
test  sets)  is  called  reconf iguration . The  SSE  must  support  this  activity. 

The  SSE  will  provide  the  environment  for  development  of  the  DMS.  Once 
developed,  the  DMS  will  be  made  available  in  the  SSE  for  application 
software/hardware  development  and  verification.  The  On-board  Data  Management 
System  will  consist  of  the  software  and  hardware  to  support  crew  control  of 
the  Space  Station  (SS)  structure  and  other  SS  subsystems.  These  systems 
include  a set  if  "core  elements"  such  as  housekeeping  data  (e.g.,  time),  a 
data  storage  system,  a Crew  Interface  system,  a network  for  support  of  a 
distributed  processing  system,  and  an  operating  system  which  supports  many 
core  and  payload  systems.  The  software  and  hardware  of  the  DMS  will  be 
configured  into  a network  of  Standard  Data  Processors  (SDP's),  Network 
Interface  Units  (NIU's),  and  data  buses  connecting  sensors/effectors  into  a 
network (s) . 

Ihe  SSL  can  be  made  available  to  the  customer  community  as  an  optional, 
service.  This  will  be  a necessary  service  for  any  customer  desiring  to  use  an 
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onboard  SSDS— provided  standard  data  processor  that  may  be  shared  among 
customers.  This  greatly  facilitates  customer  application,  software  build, 
integration  and  checkout.  If  a customer  provides  his  own  dedicated  onboard 
processor  , his  use  of  the  SSE  will  largely  depend  on  his  preferences  for 
processor  type,  implementation  language  and  existing  development 
tools/facilities.  Due  to  the  diverse  nature  of  the  customer  community  and 
their  available  resources,  it  is  unlikely  that  any  concensus  standardization 
will  emerge  in  these  areas.  The  SSE  service  will  provide  little  utility  for 
those  customers,  that  do  not  adopt  the  level  of  commonality  imposed  by  the 
SSE.  However,  for  those  customers  that  choose  to  use  the  common  SSE, 
potential  benefits  include  the  development  of  a "reusable"  software  base  that 
can  be  made  available  to  new  customers  and  the  availability  of  a stable 
development  environment. 

3 • 7 Key  Design  Drivers 

Several  SSDS  requirements  or  requirement  categories  have  been  identified  as 
"drivers"  in  the  sense  that  they  have  a particularly  strong  influence  on  the 
design  and  cost  of  the  SSDS.  The  purpose  of  identifying  these  drivers  is 
two-fold:  (1)  to  allow  a focus  on  the  requirements  so  that  they  will  be 

specified  at  an  adequate  but  not  excessive  level,  and  (2)  to  allow  a focus  on 
particular  design  areas  and  techniques  that  might  accommodate  these 
requirements  at  lesser  complexity  and  cost.  The  key  design  drivers  are  listed 
in  fable  3.7-1  with  the  potential  impacts  of  each  driver. 

All  of  the  requirements  must  be  implemented  with  a consideration  of 
affordability  - in  both  an  initial  and  a life-cycle  cost  context.  The 
identification  of  the  key  design  drivers  is  intended  to  provide  some  cost 
leverage  by  indicating  the  areas  of  SSDS  requirements  and  design  which  most 
significantly  affect  costs.  They  provide  priorities  for  requirements  analysis 
and  review,  design  innovation,  and  advanced  development. 
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fable  3.7—1  Key  SSDS  Design  Drivers 


Requirement 

• High  Mission  Peak/Average  Data  # 

Rates  * 

• 

• Automation/Autonomy  • 

• Geographic  Distribution  of  Elements  • 


• On-Orbit  Integration  • 

• 

• Evolutionary  Growth/Technology  • 

Accommodation  • 


Potential  Impacts 

Communications  Bandwidth/Buffering 

Processing  Throughput 

Data  Storage  Capacity  and  I/O  Rates 

Software  Development  Costs 
Onboard  Processing  Capacity 
Flexibility/Adaptability  of  Onboard 
Design 

Extent  of  Communication  Network 
Network  Management  Complexity 
Distribution  of  Processing  and 
Data  Base 

Subsystem  and  Module  Autonomy 
Ground  Processing/Verif ication 
Capability 

Autonomy/modulari ty  approach 
Selection  of  standards 
IOC  Resource  margins 
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4.0  EI\ID-T0-EI\1D  SSDS  DESIGN  AND  OPERATIONS  PERSPECTIVE 

By  way  of  review,  the  approach  used  to  develop  the  top-level  architectural 
topology  of  the  SSDS  was  to:  1)  define  data  processing  functions  and  resource 

requirements;  2)  iteratively  partition/subdivide  the  functions  and  allocate 
them  to  logical  entities  (nodes,  elements,  facilities,  subsystems,  ...  ),  and 
3)  continue  the  process  until  all  functions  had  been  assigned  to  physical 
entities  and  a logical  interconnection  matrix  had  evolved.  The  results  of 
this  process  were  discussed  in  section  3.0  and  lower-level  definitions  for 
space  and  ground  elements  are  provided  in  sections  6.0  and  7.0,  respectively. 

This  top-down  approach  leads  to  well-defined  end  products  that  can  be 
characterized  in  terms  of  their  resource  and  interface  requirements  (within 
the  context  of  a total  system  architecture) . However,  it  is  equally  important 
to  ensure  that  the  "modularization"  of  the  SSDS  is  consistent  with  SSIS  goals 
to  retain  an  end— to— end  design  perspective.  This  requires  the  development  of 
"unifying"  design  concepts  across  SSDS  entities  that  facilitate  the  flow  of 
data/command s between  the  onboard  payloads/subsystems  and  the  ground  or  space 
based  users.  This  section  will  describe  design  concepts  at  a sufficient  level 
of  detail  to  identify  key  end— to— end  implications  for  system  definition.  This 
will  be  accomplished  within  the  framework  shown  in  figure  4.0-1  and  includes  a 
description  of  (1)  payload/subsystem/user  operations  scenarios,  (2)  standard 
SSDS  interface  services,  and  (3)  data/command  transport  services.  These  throe 
components  will  be  discussed  in  subparagraphs  4.1,  4.2,  and  4.3,  respectively. 

A key  element  of  this  description  will  be  a relatively  detailed  examination  of 
the  appropriate  use  of  standard  communication  protocols  with  an  end-to-end 
perspective.  The  technique  employed  here  includes  the  step-by-step  tracing  of 
information  "threads"  through  the  SSDS  network.  To  accomplish  this,  design 
concepts  will  be  introduced  (based  on  the  system  definitions  established  in 
sections  6 & 7)  that  are  necessary  to  provide  a detailed  understanding  of  how 
standard  communications  protocols  can  be  effectively  used. 
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Services 
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— CMD  Management 

— Etc. 
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Figure  4.0-1.  End-to-End  Architecture  (Experiments) 


4 . 1 Pay load/Subsystem  User  Operation  Scenarios 

4.1.1  Introduction 

This  section  describes  an  end-to-end  design  perspective  from  the  customer 
payload  and  subsystems  operator  points  of  view;  it  includes  considerations  of 
the  various  operational  scenarios  encountered  by  customers  and  operators  of 
the  SSDS,  their  interfaces  and  interactions  with  their  payloads  and 
subsystems,  and  the  end-to-end  data  flow  and  routing  associated  with  payload 
and  subsystem  operations.  Data  flow  and  routing  that  support  these  scenarios 
will  be  developed  later  in  paragraph  4.3  in  terms  of  a standards  model  that 
illustrates  the  protocols  used  on  an  end-to-end  basis  and  the  degree  of 
standardization,  compatibility,  and  commonality  that  should  be  realizable  in 
the  SSDS . 

t 

This  section  will  discuss  only  a small  subset,  but  an  important  one,  of  all 
the  operational  scenarios  that  could  be  expected  to  occur  in  the  SSDS;  this 
subset  has  been  selected  to  show  an  in-depth  understanding  of  the  end-to-end 
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protocol  requirements . For  a complete  and  comprehensive  discussion  on  a more 
extensive  set  of  scenarios,  the  reader  is  referred  to  the  Task  1 report. 
Reference  1 . 

The  contents  of  this  section  are  applicable  to  the  ground  operations  and  the 
onboard  operations  for  the  Information  and  Data  Management  Systems  (IDMS)  on 
the  Space  Station  (SS),  Co-Orbiting  Platform  (COP),  Polar  Orbiting  Platform 
(POP)  and  other  SS  Program  Elements  (SSPEs). 

The  design  perspective  discussed  herein  was  developed  using  the  criterion  that 
if  customer  interfaces  (onboard  and  ground,  and  in  all  planning,  design,  test 
and  operation  phases)  are  designed  to  be  "friendly"  and  "easy  to  use"  then 
broad  acceptance  of  the  SS  Program  by  the  commercial  and  scientific 
communities  can  be  expected. 

The  end— to— end  operations  perspective  encompasses  the  following  physical  nodal 
extremes:  core  subsystems  and  payload  packages  integrated  via  point-to-point 

links  and  the  onboard  local  area  networks  (LANs)  in  the  various  SSPEs, 
space/ground  communications  and  the  use  of  special  TDRSS  uplink/downlink 
protocols,  and  the  ground-to-ground  world-wide  area  communications  network. 

The  wide  area  network  includes  the  interconnection  of  subnetworks  (e.g., 
ground  based  LANs  in  the  various  centers)  via  long  haul  satellite  and 
terrestrial  communication  links.  The  wide  area  network  has  unique 
characteristics , as  compared  with  public  data  networks,  including: 

• significant  control  by  NASA, 

• the  use  of  high  level  coding  such  as  Reed-Solomon  to  detect  and 

correct  errors, 

• transport  of  both  interactive  and  non-interactive  messages, 

• functions  such  as  data  capture  which  support  recovery  of  lost 
application  data, 

• data  encryption  and  customer  payload  security, 

• customer  data  privacy, 

• data  that  is  transported  through  the  network  that  can  be  interpreted 
as  commands  and,  hence,  must  be  checked,  in  some  instances  i.n 
realtime,  for  restrictions  and  constraints  (station  safety  and 
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experiment  cross-interference) , and 

• transport  of  critical  data  (with  retransmission  upon  detection  of 
non-correctable  error)  and  non-critical  data. 

The  SSDS  provides  data  transport  services  for  both  real  time  and  non-realtime 
messages,  highly  interactive  (e.g.,  teleoperated)  and  non-interactive 
operations,  high  and  low  rate  quick-look  and  production  data,  image  and 
non— image  data  and  in  both  realtime  and  (delayed)  non— realtime,  commercial 
quality  imagery,  low-resolution  freeze-frame  and  high  resolution  TV,  audio  and 
teleconferencing  among  nodes  in  the  SSDS.  The  SSIS  extends  the  nodes  to  the 
customers  facilities,  and  provides  data  transfer  services  among  all  nodes. 

4.1.2  Customer  Interface  Definition  and  Interaction 

The  development/operation  cycle  of  a payload  includes  the  following  phases: 
Feasibility  analysis,  mission  planning,  payload  development,  ground 
integration  and  verification  testing,  transportation  to  space,  onboard 
integration  and  verification  testing,  payload  operations  (production, 
maintenance,  etc.)  and  finally,  transport  back  to  earth. 

In  the  feasibility  analysis  and  planning  stages,  resource  requirements , 
distribution  of  resources,  cost  of  resources,  and  operational  constraints  must 
be  established  to  determine  the  overall  feasibility  of  a particular  mission. 
Considerations  here  include  the  following: 

1.  Power  Resources  Allocation  — The  user  power  requirements  must  be 
known  for  long  range  planning  and  for  near  term  operations  control. 

2.  Timeline  Constraints  - Constraints  associated  with  orbital  position 
(earth  viewing),  daylight  or  darkness  or  any  other  timeline 
constraint  must  be  integrated  into  the  plan  to  develop  realizable 
operational  windows. 

3.  EVA  Servicing  - EVA  is  treated  as  a mission  resource  and,  whether 
required  on  a one-time  or  periodic  basis,  must  be  established  and 
factored  into  mission  planning  and  crew  timeline  planning  to 
determine  resource  requirements  and  availability. 
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4.  Computing  and  Data  Storage  Resource  Allocation  - The  data  processing 
requirements  for  the  experiment  must  be  developed  by  the  user  and 
factored  into  his  planning.  Also  any  realtime  constraints  associated 
with  realtime  control  (such  as  transport  lag  or  jitter  experienced 
through  the  SSDS  network)  will  be  provided  to  the  user  so  that  he  can 
develop  criteria  for  space/ground  autonomy  decisions.  If  the  user 
intends  to  use  SSDS  hardware  resources  (processing,  I/O,  memory, 
workstation,  ...)  then  these  must  be  identified  and  integrated  into 
the  mission  plan. 

5.  Crew  Monitor  and  Control  - If  the  payload  operations  are  to  be 
managed  by  the  flight  crew,  the  crew  monitor  and  control  requirements 
must  be  factored  into  crew  mission  timelines.  In  addition,  crew 
training  must  be  planned  and  integrated  into  mission  preparation. 

6.  Software  Development  Resource  Allocation  — If  the  user  wishes  to  use 
the  SSE  then  he  must  estimate  the  resources  required  to  develop  the 
experiment  applications  software  and  these  resources  must  be  factored 
into  programmatic  decisions  and  long  range  planning. 

7.  Communication  Link  Resource  Allocation  - The  user  must  estimate  the 
full-  and  half-duplex  communication  resources  required  to  control  his 
payload  and  to  transport  his  data  from  orbit  to  ground  data  handling 
facilities.  This  will  allow  for  mission  planning  and  assignment  of 
communication  network  resources.  These  estimates,  along  with  network 
communication  scheduling  constraints,  must  be  planned  and  integrated 
into  the  mission  plan. 

8.  Develop,  Simulate,  Integrate  and  Train  (DSI&T)  - The  user  must 
estimate  the  resources  required  in  the  DSI&T  element.  Key  decisions 
here  will  affect  how  he  intends  to  develop  and  integrate  his  payload 
(planned  use  of  his  facilities,  SSDS-supplied  interface  simulators, 
DSI&T  integration  services,  ...). 

9.  Standard  Services  - A key  decision  in  the  customers  planning  phase 
will  be  the  selection  of  standard  services  provided  by  the  SSIS  (some 
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of  which  were  discussed  above,  and  all  of  which  are  discussed  in 
paragraph  4.2). 

As  part  of  the  planning  and  preliminary  design  activity  the  customer  will  have 
to  perform  automation  and  allocation  trade  studies  analogous  to  those 
performed  for  non-payload  functions  (e.g.,  core  subsystems).  Issues  to  be 
resolved  here  are  the  following: 

1.  How  should  a payload's  functions  (e.g.,  data  acquisition/processing/- 
compression,  command/control,  ...  ) be  distributed  between  the 
customer's  supplied  payload  package,  onboard  SSDS  resources,  ground 
SSDS  facilities  and  resources,  and  the  customers  own  ground 
facilities?  How  should  ancillary  data  be  acquired  (onboard  or 
ground)? 

2.  What  degree  of  automation  should  the  customer  incorporate  into  his 
payload  operations  phases  (quick  look  verification,  production 
quality  tests,  machine  diagnostics,  ...  )? 

3.  What  development  methodology  should  the  customer  employ  so  that  he 
will  have  continuity  through  his  proposal,  development,  fabrication, 
testing,  integration,  operations,  data  reduction,  analysis,  and 
archiving  phases?  For  example,  can  the  system  be  built  so  that  a 
user  can  employ  a single  set  of  equipment  and  software  to  check  his 
instruments  before  delivery,  during  integration,  and  periodically 
during  operation?  Can  instrument  calibration  traceability  be 
achieved? 

4.  For  the  various  classes  of  payloads,  what  should  the  relative  roles 
be  for  the  scientist/astronauts,  flight  crews,  mission  controllers, 
instrument  controllers,  and  the  users  during  the  operations  phases? 
Who  will  have  decision-making  authority  for  different  user-related 
activities  and  for  different  mission  timelines? 

For  items  1 and  2 above,  the  methodology  to  be  used  that  implements  a 
procedure  that  leads  to  an  "optimal"  payload  function  allocation  and 
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automation  realization  is  similar  to  the  one  used  in  the  Task  3 Function 
Allocation  and  Automation  trade  study.  The  exception  is  that  the  procedure 
would  be  interactive  between  the  customer  and  a customer  information  support 
function.  Resource  costs  and  constraints  would  be  clearly  identified  in  this 
interaction. 

For  item  4 above,  the  roles  of  crew  personnel  and  their  relative  authority  in 
making  decisions  relative  to  payload  operation,  is  deferred  to  a future 
programmatic  study. 

4.1.3  Scheduling  and  Session  Establishment 

The  customer  is  an  individual  or  organization  with  an  interest  to  place  a 
pay  load/experiment  in  an  SSPE  and  to  use  the  standard  communication  and 
processing  facilities,  and  other  standard  services  provided  by  the  SSIS. 
Onboard,  the  customer  payload  is  supported  by  Space  Station  or  platform 
facilities  such  as  a pallet  with  power,  active  thermal  control,  communication 
interfaces,  and  if  required,  a pointing  and  tracking  capability  or  a 
pressurized  module.  The  customer  provides  an  experiment  compatible  with  the 
SSPEs  electrical,  mechanical,  thermal,  dynamic  and  other  interfaces,  as 
specified  in  the  SSPE's  Interface  Control  Drawing  (ICD) . On  ground,  the 
customer  can  conduct  his  payload  operations  from  his  own  facility  or  from  one 
contained  within  the  SSIS. 

The  end-to-end  architecture  from  the  customer's  point  of  view  was  shown  in 
Figure  4.0-1.  Standard  onboard  payload  services  and  ground  interface  services 
are  provided  as  shown  in  the  figure  and  as  further  expanded  later  in  paragraph 
4.2.  The  data  transport  service  presents  a simple,  easy-to-use,  and 
transparent  interface  both  onboard  and  onground  (i.e.,  the  real  complexities 
of  the  command  and  data  transport  process  are,  in  all  cases,  hidden  from  the 
customer). 

The  customer  operations  with  his  payload  can  be  conducted  onground  from  a 
Payload  Operation  Control  Center  (POCC),  Regional  Data  Center  (RDC)  or  in  his 
own  facility,  or  in  space  using  an  MPAC  or  his  own  custom  workstation.  This 
is  depicted  in  Figure  4. 1.3-1  which  shows  a payload  connected  to  a local  area 
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network  (LAN)  via  a standard  network  interface  unit  (NIU)  and  operations  being 
conducted  from  onboard.  This  figure  illustrates  two  standard  options  for 
interfacing  a payload:  one  where  the  customer  connects  his  payload  using  only 

a standard  I/O  interface  (e.g.,  RS422,  MIL-STD-1553 , ...  ) and  the  other  where 
he  supplies  all  of  the  data  processing  equipment  except  for  the  network 
interface  (an  SS-supplied  card-set)  at  the  LAN  medium. 
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Figure  4.1.3-1.  Customer  Standard  Onboard  Interfaces 

In  either  case,  when  the  customer's  payload  is  delivered  to  orbit,  and  is 
mechanically,  thermally,  and  electrically  integrated,  communication  with  the 
payload  can  be  initiated  via  the  end-to-end  data  distribution  system.  Command 
control  and  sensor  data  are  distributed  using  this  system  and  data  and  program 
storage  services  are  available  from  onboard  mass  storage  devices  (for 
proprietary  and  other  reasons,  the  customer  may  elect  to  embed  his  program 
code  in  his  package  and  make  it  non-access ible  to  the  external  world  or  he  may 
elect  to  encrypt  it  and  uplink  it  every  time  his  payload  is  activated). 
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The  customer  will  provide  the  application  software  to  command  and  control  his 
payload;  this  software  can  be  divided  into  four  components: 

1.  Onboard  data  processing 

2.  Onboard  workstation  processing 

3.  Ground  data  processing 

4.  Ground  workstation  processing 

When  the  payload  is  active,  the  data  processing  software  is  resident  in  the 
customer's  processors  (1  and/or  3 above)  and  the  workstation  processing 
software  is  resident  in  the  customer's  workstations  (2  and/or  4 above).  When 
the  experiment  is  inactive  the  customer's  software  may  be  stored  on  a mass 
storage  device.  Data  processing  deals  with  command  processing,  sequencing, 
data  manipulation  (e.g.,  transformation,  filtering),  status  monitoring,  and 
payload  production  and  performance  data  acquisition  associated  with  the 
experiment.  Workstation  processing  includes  graphics  processing,  display, 
command  entry,  and  interactive  processing  to  support  the  experiment  for 
quick-look,  production,  diagnostic,  and  other  operations  phases. 

If  the  customer  uses  standard  services,  including  the  SSE  and  a high  order 
language  (HOL),  he  will  then  develop  application  software  which  may  utilize 
real-time  statements  and  which  must  be  compiled  from  HOL  source  statements 
into  a machine  load  module.  The  customer,  therefore,  must  be  familiar  with 
the  software  development  language,  including  the  real-time  features  of  this 
language.  Software  development  will  generally  be  conducted  on  ground  but 
onboard  development/compilation  is  not  excluded. 

Payload  Requests  for  Service 

This  subsection  will  discuss  the  operations  associated  with  activating  a 
payload  and  attaching  it  and  its  associated  control  centers,  workstations, 

....  to  the  SSDS  Data  Distribution  Network.  These  discussions  will  be  in 
terms  of  the  data  flow  diagrams  included  in  Appendix  D.  A brief  discussion  of 
these  diagrams  is  presented  here  to  show  the  flow  of  requests  for  service. 
Customer/operator  requests  for  services  or  delivery  of  commands,  are  initiated 
in  two  places  (see  diagrams  and  locate  blocks  0001);  schedule  requests  (for 
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future  service  or  on-demand  activation)  go  directly  to  Function  3.0,  Schedule 
and  Execute  Operations.  Payload  and  core  commands  (real  and  non-real  time) 
pass  through  Function  2.0,  Manage  Customer/Operator  Supplied  Data  for 
authentication  (log-on,  etc)  checks,  and  for  restricted/constrained  tests  and 
are  then  transported  to  Function  3.0  where  they  are  scheduled  for  future 
execution  (non-real  time)  or  are  sequenced  for  real  time  execution.  Payload 
activation  will  be  controlled  by  Function  3.4.1,  Sequence  Payload  Operation, 
and  network  attachment  will  be  implemented  via  Function  3.4.2,  Sequence  Core 
System  Operation,  whose  command  outputs  are  eventually  passed  to  Function 
4.2.5. 1,  Communication  Network  Control. 

Payload  sequencing  operations  (Function  3.4.1)  involve  functions  like 
connection  of  the  payload  to  the  TCS,  application  of  prime  power,  . . . , and  are 
not  discussed  any  further  in  this  section.  The  continuing  discussion  here 
will  be  directed  towards  the  operations  in  Function  4.2.5. 1,  Communication 
Network  Control,  that  attach  the  payload,  the  customer,  and  other  entities 
onto  the  network  and  bind  these  entities  into  a SESSION. 

Payload  Session  Services 


Payload  session  services  are  one  component  of  a set  of  services  collectively 
called  Network  Management  (see  Figure  4. 1.3-2,  especially  item  number  1)  that 
are  distributed  between  the  onboard  SS  function  4.2.5. 1,  Communication  Network 
Control,  and  various  ground  element  functions.  These  generic  network 
management  functions  are  further  defined  in  Figure  4. 1.3-3  which  shows  a 
function  characterization  and  allocation.  In  this  figure,  functions  3 and  4 
are  self  explanatory  and  are  not  involved  in  session  establishment.  Function 
2 includes  setting-up,  maintaining,  and  disconnecting  sessions,  while  Function 
1 is  the  implementation  of  IS0/0SI  layers  1-7  after  a session  is  established. 

For  SSDS,  connections  are  generally  established  between  all  the  entities  that 
are  involved  in  command/data  transactions  between  ground  components  and  space 
payloads  or  core  subsystems.  The  tenure  of  a session  may  be  momentary  or  it 
may  be  permanent  depending  on  the  application.  A session  binds  entities  into 
a contract  to  provide  resources  and  services  for  a data  transaction 
operation.  At  session  establishment  time,  protocols  and  other  services  to  be 
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1.  Session  services 

• Request  to  have  sessions  are  received. 

• The  session  requests  are  validated. 

• Resources  are  allocated  to  sessions. 

• Subchannels,  table  entries,  session  identifiers,  etc.,  are  assigned 

• The  route  for  the  session  is  selected.  Alternative  routes  in  case  of 
failure  may  also  be  selected.  (This  is  for  systems  without  dynamic 
routing  of  packets.) 

• The  communicating  parlies  are  bound  and  their  session  initiated. 

• When  session  is  over,  the  communicating  parties  are  unbound  and 
their  session  terminated. 

• When  failures  occur,  session  recovery  is  initiated. 

• Accounting  information  is  gathered  for  billing  purposes. 

• Requests  for  network  sessions  with  devices  of  foreign  architecture  are 
handled. 

2.  Handling  of  physical  resources 

e A directory  of  physical  resources  is  maintained  (processors,  terminals, 
cluster  controllers,  peripherals,  channels,  circuits,  line  groups,  etc.) 

• The  management  software  permits  these  physical  resources  to  be 
activated  and  deactivated 

• Dynamic  reconfiguration  may  take  place  when  failures  occur. 

• Recovery  action  may  be  initiated. 

• Information  is  provided  to  the  network  operators  to  enable  them  to 
deal  with  the  physical  resources. 

e information  is  provided  to  the  maintenance  engineers  about  the 
physical  resources. 

• Resources  are  monitored  for  performance  measurement. 

3.  Maintenance 

e Terminal  facilities  are  provided  for  maintenance  engineers  to  access 
the  network. 

• Errors  and  failures  are  logged. 

• Reports  and  analyses  of  the  errors  and  failures  are  done  and  made 
available  at  the  engineer  terminals 


• Problems  are  automatically  reported  to  a network  operator 

• Diagnostics  and  confidence  tests  are  run.  possibly  triggered 
automatically,  possibly  by  an  operator  or  engineer. 

• Decisions  to  take  down  network  components  or  circuits  are  made, 
based  on  the  severity  or  frequency  of  errors. 

4.  Security 

• A surveillance  log  is  maintained  of  all  security  procedural  violations. 

• The  surveillance  log  is  analyzed  for  the  security  officer,  highlighting 
occurrences  needing  immediate  attention. 

e T riggering  of  alarms  on  detection  of  certain  types  of  procedural 
violations. 

• Files  of  passwords,  cryptography  keys,  or  other  security  information 
are  securely  managed. 

e Terminals  are  provided  for  security  officer  functions. 

5.  Administration 

• Terminals  are  provided  for  network  operators. 

• The  operators  can  display  details  of  the  network  and  its  various 
resources. 

• The  operator  can  start  and  stop  the  network. 

• An  operator  can  activate  and  deactivate  network  components. 

• An  operator  can  start  and  stop  application  programs. 

• An  operator  can  reconfigure  the  network  dynamically  (i.e.,  without 
shutting  it  down). 

• An  operator  can  change  specifications  of  network  control  mechanisms 

• An  operator  can  down-line  load  programs 

• An  operator  can  initiate  a dump  of  programs  in  peripheral  machines, 
possibly  transmitting  the  dump  to  a larger  machine  for  printing. 

• An  operator  can  initiate  trace  or  statistics-gathering  programs 

• An  operator  can  initiate  performance  measurement  aids. 

• Network  performance  can  be  measured,  analyzed,  and  possibly 
experimented  with. 

• Information  is  collected  for  billing  users  and  bills  are  prepared. 


‘Reference:  Martin,  James,  Computer  Networks  and  Distributed  Processing,  Software,  Techniques,  and  Architecture, 
Prentice  Hall,  Inc.,  Englewood  Cliffs.  N.J.,  1981 


Figure  4. 1.3-2.  Generic  Network  Management  Functions* 


Functions 

Characteristics/Allocation 

1 

REAL  TIME  CONTROL  Includes  operation  of  the 
hardware  and  software  functions  associated  with 
network  data  flow  after  a session  is  established.  This 
encompasses  OSI  layers  1-7. 

Real  time,  automated,  distributed  space  and 
ground  NIUs  and  SDPs 

2 

SESSION  MANAGEMENT  Refers  to  functions  not 
included  in  1 above  that  are  required  to  initiate/terminate 
sessions,  and  provide  for  checkpoint/restart,  automatic 
recovery,  and  switchover. 

Real  time;  automated,  distributed  space  and 
ground,  but  principally  allocated  to  function 
4.2.5.1,  Communication  Network 
Control. 

3 

MAINTENANCE  Refers  to  the  primarily  automated 
activity  of  keeping  the  network  running.  Nodes  in  the 
network  log  errors  and  provide  overall  statistics  to  this 
function  which  responds  with  commands  to  execute 
diagnostics  to  fault-isolate  failed  components. 

Real  and  nonreal  time,  automated  and 
interactive,  allocated  to  space  and 
ground  elements 

i 

ADMINISTRATION  Refers  principally  to  the  human 
activities  associated  with  operating  the  network.  The 
administrator  monitors  network  performance  (e.g., 
statistics  for  utilization,  lost  data  events, . . .).  The 
administrator  is  a special  type  of  end  user  and  requires 
activity  reporting  functions  throughout  the  network. 

Nonreal  time,  interactive  and  manual, 
allocated  to  NCC 

Figure  4.1. 3-3.  Network  Management  Functions 
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used  in  the  session  are  agreed  to  by  the  communicating  parties.  Examples  of 
services  and  resources  are  as  follows: 

• Full-  and  half-duplex,  and  virtual  and  real  communication  channels 
with  requested  bandwidths 

• Protocol  selection  (EBCDIC,  ASCII,  NAPLBS,  ...) 

• Context  selection  (Virtual  File  Transfer,  ...) 

• Processing  resources  (Ops/sec)  at  DHC,  POCC,  RDC,  ... 

• Memories  (main,  mass,  raw  data  buffers,  ...)  onboard  or  at  DHC,  POCC, 
RDC,  . . . 

There  are  alternatives  to  the  establishment  of  a session  (e.g.,  connectionless 
or  datagram  services)  but  it  is  felt  that  established  sessions  will  provide 
the  transport  reliability  required  by  most  customers  (see  Figure  4. 1.3-4).  A 
distinction  between  connection  and  connectionless  service  is  shown  in  Figure 
4 . 1 . 3—5  for  an  (l\l)— Layer  (N=2,3,...7)  entity  in  the  OSI  model  (the  customer's 
interface  with  the  OSI  model  is  discussed  later  in  paragraph  4.3). 


Data  Type 

Volume 

Delay 

Requirements 

Reliability 

Requirements 

Transport  Service 
(Layer  4) 

Voice 

S 

H 

L 

Video 

L 

H 

L 

Bulk  Digital  Data 

L 

L 

H 

Connection,  Class  4 

Payload  Data 
Ouickiook 

M 

H 

Connection,  Class  0 

Production 

L 

L-H 

L-H 

Connection,  Class  0-4 

Commands 
— Payload 
— Core 

S 

H 

H 

Connection,  Class  0-4 

Engineering  Telemetry  and 
Payload  Performance 

S 

H 

M 

Connection,  Class  0 

Data  Base  Queries 
and  Maintenance 

M 

H 

H 

Connection,  Class  4 

S = Small 
M = Medium 
L = Large 

H = High  (or  “Strict”)  Requirements 
M = Medium  Requirements 
L = Low  Requirements 

Figure  4.1. 3-4.  Data  Types  and  Transport  Service 
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One  final  point  concerning  Function  2,  Session  Management,  in  Figure  4. 1.3-2 
is  that  this  function  can  be  implemented  in  a centralized  or  distributed 
manner  as  shown  in  Figure  4. 1.3—6.  Both  approaches  are  used  in  modern  data 
networks  and  both  have  desirable  features  for  the  SSDS,  as  shown.  In  the 
distributed  approach,  the  payload,  for  example,  when  activated  would 
autonomously  establish  and  maintain  its  session  with  the  appropriate  elements 
(e.g.,  POCC,  SDC,  MPAC,  and  would  disconnect  those  elements  when 

requested  by  the  POCC  or  the  Function  3.0  scheduler.  In  this  approach  the 

network  nodes  do  not  have  the  global  visibility  required  for  optimal  resource 
allocation  and  are  more  susceptible  to  security  breaches.  Centralized 
management  offers  other  features  as  shown  in  the  figure.  The  multi-centered 
option  has  been  selected  for  the  SSDS  and  is  discussed  further  in  paragraph 
4.5.10 


Negotiate/Allocate/Reserve 

Resources 

■ Buffers/Processors 

■ Data  Links 

■ Protocol 

■ Quality  of  Service 


Connection-Oriented  Interaction 


Peer-to-Peer  Processes 


Data 

(N)-Layer 

Acknowledge  Option 

(N)-Layer 

Transmission  of 
Independent/Unrelated 
Data  Units 

■ Datagrams 

■ Best  Effort 
Activity 


Connectionless-Oriented  Interaction 


Figure  4. 1.3-5.  Connection/Connectionless  Service 
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Distributed 

Management 


• Distributed 
Management 
Communicating  parties 
handle  sessions  without 
the  aid  of  a third-party 
manager 


Primary-secondary 
✓ relationship  between 
//  the  parties 


Symmetrical  (peer-coupled) 
relationship  between  the 
parties 


DECENTRAL  PRIMARY  SECONOARD  MANAGEMENT  • 


Trend  is  to  Distribute 
Session  Management 

Used  in  ARPANET 
and  DECNET 


e 


e Potentially,  More 
Optimal  Allocation  of 
Resources  and  Better 
Route  Selection  for 
Session 

e Used  in  SNA 
and  DCA 


Figure  4.1. 3-6.  Centralized/Distributed  Network  Management  Options* 


4.1.4  Payload  Development  and  Activation 
Ground  Tests 


The  customer  software  and  hardware  must  be  integrated  and  verified  before 
being  transported  to  space  and  ground  elements.  The  integration  testing  will 
generally  be  done  initially  in  the  customer's  facility  where  he  can,  as 
required,  employ  commercial-quality  equivalents  for  MPACs,  onboard  data 
processors,  or  a local  area  network/data  network  simulator  which  emulates  the 
end-to-end  wide-area  and  local-area  networks  including  communication  delays. 

A second  phase  may  be  conducted  where  the  customer  performs  crew  training  and 
validates  his  payload  interfaces  and  operations  via  the  SSDS  Develop,  Support, 
Integrate  and  Train  facility. 

Software  Transport  to  Space  and  Ground  Facilities 

In  the  development  herein,  it  should  be  recalled  that  there  are  four 
components  of  customer  software  that  support  the  payload:  ground  and  space 

workstations  and  ground  and  space  processors. 
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The  ground  programs  for  both  workstation  and  processors  are  delivered  to 
ground  facilities  by  electronic  transfer  or  by  portable  media  (tape,  etc.). 

The  programs  are  loaded  into  the  ground  facility  mass  storage  devices  and 
appropriate  directories  are  updated  to  allow  the  ground  facilities  management 
function  and  system  executive  to  recognize  a request  (from  a ground 
workstation  or  a telecommand  from  orbit)  for  these  programs  to  be  loaded  into 
the  ground  workstation  and  ground  processor  for  execution.  On  the  ground  this 
will  likely  be  managed  by  a modified  commercial  system  executive.  This 
machine  management  is  transparent  to  the  customer. 

The  customer  programs  to  be  uploaded  to  the  space  system  are  loaded  in  a 
similar  fashion.  An  electronic  transfer  is  accomplished  via  a telecommand 
which  contains  the  code  and  will  also  contain  labels  defining  restricted  and 
constrained  command  sequences  embedded  in  the  code.  The  incoming  programs  are 
addressed  to  a mass  storage  utility  function  which  places  the  programs  on  mass 
storage  and  then  updates  appropriate  directories  to  allow  the  onboard 
facilities  management  function  and  system  executive  to  recognize  a request  for 
these  programs  to  be  loaded  into  the  payload  processors  and  on-orbit  customer 
workstations  for  execution.  The  origin  of  this  request  for  loading  and 
execution  may  be  a telecommand  from  ground  or  from  an  on— orbit  workstation 
configured  to  communicate  with  the  ground  facilities  management  function. 

Payload  Activation/Deactivation 

Payloads  are  activated  via  the  request  sequence  discussed  earlier  in  section 
4.1.3.  Requests  can  be  initiated  from  ground  workstations  or  onorb.it 
workstations.  Typical  scenarios  would  be  1)  where  a customer  would  LOGON  from 
his  workstation  in  anticipation  of  his  upcoming  scheduled  session  with  his 
payload  and  query  the  schedule  function  to  verify  there  had  been  no  schedule 
changes,  and  2)  where  a customer  would  LOGON  to  request  a non-scheduled 
session  with  his  payload. 

The  sequence  depicted  earlier  in  section  4.1.3  will  validate  the  authorization 

* 

of  the  customer  and  coordinate  the  planning  for  an  unscheduled  session.  If 
authorization  is  not  approved  due  to  scheduling  or  unrecognized  user  II),  then 
the  user  would  be  blocked  and  his  workstation  would  receive  an  abort  message 
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(with  abort  reason).  If  the  customer  is  authorized  to  proceed  with  activation 
and  control  of  his  payload  the  onboard  DMS  establishes  a session  with  all 
elements  required  in  the  session,  and  they  are  automatically  configured  to 
support  the  payload  operations.  Workstations  and  processors  throughout  the 
SSDS  will  be  loaded  with  appropriate  software  communication  resurces  will  be 
reserved  for  the  duration  of  the  session. 

At  this  point  the  customer  is  now  in  contact  with  his  supplied  application 
programs  which  can  power  up  and  sequence  the  experiment  and  gather,  analyze 
and  process  data.  This  data  can  also  be  acquired  and  delivered  to  ground 
and/or  space  processors  through  the  data  distribution  and  communication  link 
for  analysis.  The  customer  may  self-buffer  his  data  or  use  the  onboard  mass 
store  and  data  base  manager. 

The  session  establishment  may  have  included  a part-time  or  full-time 
high-bandwidth  communication  channel  to  route  quick-look  data  to  the  POCC 
prior  to  entering  the  production  phase.  Other  scenarios  could  include 
consideration  for  payload  integration,  diagnostics,  checkout,  maintenance, 
quality  tests,  combined  ground  crew  and  space  crew  operations,  and  so  forth. 

When  the  experimenter  has  completed  his  mission  or  his  scheduled  time  has 
elapsed,  the  payload  will  be  deactivated.  Prior  to  scheduled  time  expiration 
the  customer  will  receive  a message  alerting  him  that  his  payload  is  scheduled 
to  be  deactivated  at  time  XXX. XXX.  If  the  programs  are  controlled  from  the 
ground,  then  the  ground  site  must  first  request  that  the  onorbit  programs  be 
terminated  and  entities  in  the  session  be  disconnected.  This  will  remove 
these  programs  from  execution  and  release  the  resources  used  in  the  session. 
The  programs  will  still  remain  on  the  mass  storage  devices  until  these  files 
are  requested  to  be  purged.  The  customer  can  then  deactivate  the  ground 
programs  by  requesting  the  ground  site  facilities  management  to  terminate  his 
programs.  This  will  cause  the  ground  resources  to  be  released. 

4.1.5  Interactive  Communication 

The  discussion  in  this  section  is  in  terms  of  the  diagram  in  Figure  4. 1.5-1 
which  uses  processors  and  workstations  both  onboard  and  on  ground,  in  this 
example,  at  a POCC. 
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Figure  4. 1.5-1.  Interactive  Operations 


When  the  payload  is  delivered  to  the  SS  and  physically  connected  to  the  LAW, 
the  WIUs  physical  address  embedded  in  the  WIU  is  provided  to  the  network 
manager  who  will  associate  it  with  an  object  name  and  one  or  more  application 
process  IDs.  At  session  establishment  time,  the  network  manager  attaches  each 
of  the  customer's  tasks  (located  in  processors  and  workstations)  to  the 
network . At  the  time  a task  is  loaded  into  a processor  or  a workstation,  the 
system  executive  recognizes  that  the  object  address  corresponding  to  the  task 
must  be  attached  to  the  network  and  requests  the  network  manager  to  do  so.  A 
message  from  the  network  manager  to  the  WIU  programs,  which  are  capable  of 
updating  object  address  tables,  accomplishes  this  attachment.  If  there  are 
bridges  or  gateways  that  must  be  informed  that  they  should  receive  and 
retransmit  messages  for  the  object  address  being  attached,  then  this  is  also 
accomplished  by  the  network  manager  by  sending  messages  to  the  appropriate 
bridge  or  gateways  as  sessions  are  established. 
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Real-time  monitor  and  control  can  be  accomplished  from  the  ground  or  onorbit 
or  both  depending  on  where  the  workstation  software  is  resident  for  a specific 
session. 

4.1.6  Accommodation  of  Telescience 

The  concept  of  telescience  derives  from  the  notions  shown  in  Table  4. 1.6-1. 

The  principal  components  of  the  SSDS  that  accommodate  the  above  telescience 
concepts  are  as  follows: 


Table  4. 1.6-1  Telescience  and  the  User 

1.  Payload  Control  from  home  institution 

2.  Data  delivery  to  user  with  merged  multi  sensor  and  ancillary  data, 
with  SSDS-supplied  standard  processing  (option),  for  quick-look  and 
production  processed  data 

3.  Transparency  — the  real  complexities  of  the  data  system  are  hidden 
from  the  user 

4.  Easy  electronic  access  to  numerous  data  archives  and  data  bases  for 
building  comprehensive  data  libraries 

5.  Interactive  and  realtime  operation 

6.  User  operations  in  concert  with  colleagues  in  a coordinated 
multi-sensor  and  multi-discipline  data  capture  activity 

7.  User  selections  of  equipment  (workstations,  processors , . . . ) of  his 
choice 
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Control— A customer  will  have  the  capability  to  control  his  payload 
from  his  own  facility  or  a NASA-supplied  facility,  home  institution, 
or  he  can  be  mobile  and  operate  at  both  facilities  within  certain 
constraints  such  as  the  man-machine  interfaces  of  the  workstations  at 
the  various  locations. 

Access— A customer  will  have  free  and  easy  access  to  his  payloads 
subject  to  resources,  constraints  and  restrictions,  as  described 
later.  A principal  design  objective  of  the  SSDS  is  that  it  be  as 
friendly  to  users  as  is  possibly;  some  limitations  in  this 
"friendliness"  is  necessary  based  on  considerations  of  safety, 
equipment  damage,  payload  cross-compatibilities  and  quality  of  data 
capture,  and  other  reasons,  as  outlined  later.  Electronic  access  to 
SSDS/SSIS  data  bases  will  be  provided. 

Transparency— The  SSDS  will  "hide"  all  of  the  real  complexities  of 
the  command  and  data  packet  formation  and  the  transport  of  these 
data.  The  intricacies  of  the  data  system  (i.e.,  layering,  error 
control  management,  encryption,  data  synchronization,  data 
reconstruction, . . . ) are  totally  hidden  from  the  user. 

Interactive  and  Realtime  Operations — A customer  will  be  able  to 
communicate  and  control  his  payload  as  though  it  were  physically 
located  in  the  same  room  as  his  workstation.  The  SSDS  will  only  add 
sub-second s-to-seconds  delays  to  the  transport  delay  that  would  be 
associated  with  an  immediately  adjacent  experiment.  As  an  example, 
for  the  solar  flare  activity  where  conditions  change  rapidly, 
capabilities  will  be  in  place  to  implement  instrument  adjustments  in 
a matter  of  minutes. 

Communication  and  Coordinated  Team  Involvement — Voice  and  video 
teleconferencing  will  be  implemented  between  multiple  ground  sites 
and  the  space  station  to  coordinate  multiple  team  activity  in  an 
integrated  multi-sensor  data  capture  of  scientific  phenomenon. 


6.  Operation  in  a Heterogeneous  Environment — The  customer  will  be  able 
to  configure  the  operations  center  with  the  hardware/software  of  his 
choice  subject  to  the  constraint  that  he  comply  with  the  network 
security  requirements  and  "open1'  communication  protocols  specified  by 
the  SSDS.  In  the  heterogeneous  environment,  computer-to-computer 
networking  will  be  accommodated  via  the  use  of  international  and 
national  standards  as  opposed  to  private  and  proprietary  protocols. 


4 . 2 Interface  Services 

Table  4.2-1  shows  a summary  of  onboard  and  ground  interface  services.  It 
includes  the  principal  SSDS  services  and  only  those  SSIS  services  necessary  to 
show  completeness  from  an  end-to-end  operations  perspective.  The  services  are 
discussed  in  more  detail  in  the  following  subparagraphs . 

4.2.1  Mechanical,  Electrical,  and  Thermal  Services  (SSIS) 

The  physical  mounting  of  the  payload  will  be  defined  in  an  interface  control 
drawing  (ICD)  which  is  prepared  by  the  customer  and  agreed  to  by  the  Space 
Station  Program  Office.  The  ICD  also  specifies  power,  signal,  and  thermal 
interfaces  including  connectors.  These  interface  standards  must  be  conformed 
to  and  will  be  tested  during  system  integration.  The  power  supplied  to  the 
customer  is  protected  against  overload  by  remote  power  controllers.  The 
facilities  management  function  coordinates  the  use  of  power  and  therefore 
experiment  activation  will  be  blocked  when  power  is  not  available.  This 
coordination  is  accomplished  between  the  system  executive  and  the  scheduling 
functions . 
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Table  4.2—1.  Interface  Services  Summary 


ONBOARD  SERVICES 

1.  Pallet  — Mechanical,  thermal,  power,  pointing,  motion  decoupling,  ... 
(SSIS). 

2.  Crew  - Onboard  operations,  IVA/EVA,  servicing,  diagnostics,  repair,  ... 
(SSIS). 

3.  TV/Audio  Distribution  — Internal,  external,  space— to— ground , 
space-to-space,  realtime/delayed,  conferencing,  ...  (SSIS). 

4.  Processors  - SDPs,  local  RAM,  standard  I/O  including  serial/parallel  and 
backplane  I/Fs,  distributed  operating  systems,  . . . 

5.  Mass  Store  - Programs,  files,  instrument  data,  procedures,  ... 

6.  Work  stations  - MPACs  with  standard  software  packages:  interactive 

command/control . graphics,  word  processing,  ... 

7.  Data  Base  - File  management  and  query. 

8.  Payload  Sequencing  - Activation,  scheduled,  targets  of  opportunity, 
on-demand,  . . . 

9.  Command  Management  - Restricted/constrained  checks. 

10.  Distribution  of  ancillary  data  including  time. 

11.  Error  Free  Data  Distribution  - Between  payload,  SDPs,  mass  store,  C&T 
gateway , . . . 

12.  Logistics  - Sparing  of  cards/modules  for  SDPs,  standard  I/O,  ...  (SSIS). 
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GROUND  SERVICES 


1.  Data  capture  and  error-free  transport  to  customer  designated  facilities, 
quick-look  and  production. 

2.  Processing  level  0 (standard)  and  level  1A  (optional),  archives 
electronically  accessible. 

4.  Ancillary  data  via  electronic  access. 

5.  Software  Support  Environment  - Local/remote  access,  SDP  development 

support:  HOL  compiler,  simulators,  assembler,  ...,  standard  programs 

(library) . 

6.  Develop,  Simulate,  Integrate  and  Train  - Payload  development,  SSDS 
integration,  crew  and  mission  specialist  training,  simulators,  .... 

7.  Payload  Operation  Facilities  - Workstation,  processors,  mass  store,  ..., 
at  POCC,  RDC,  . . . 

ONBOARD  AND  GROUND  COMMON  SERVICES 

1.  End-to-End  Error  Free  Data  Transport. 

2.  Security/Privacy  - Physical  payloads,  programs,  data,,  procedures , ... 

3.  End-to-End  Voice/Video  Services. 

4.  End-to-end  scheduling  including  suport  of  on-demand  services. 

5.  Control  of  payloads:  onboard,  on  ground  at  POCC  or  at  home  institution. 
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In  general,  the  customer's  payload  will  dissipate  energy  and  active  thermal 
control  will  be  required.  The  customer  will  be  provided  with  a thermal 
control  subsystem  (TCS)  interface  which  is  activated  prior  to  the  equipment 
being  powered  ON.  In  the  event  of  an  overload  the  customer  may  be  deactivated 
to  reduce  the  load  on  the  TCS.  The  facilities  management  function  coordinates 
the  use  of  the  thermal  control  capacity  and  may  block  activation  of  the 
payload  when  capacity  is  exceeded. 

4.2.2  EVA  Services  (SSIS) 

The  customer  experiment  can  be  serviced  by  EVA  for  refurbishment  or  repair. 

4.2.3  Pallet  Pointing  (SSIS) 

Active  decoupling  of  platform  motion  can  be  provided  by  an  isolated  pallet  for 
customer  payload  precision  pointing. 

4.2.4  Operations  and  Crew  Interaction  (SSIS) 

The  payload  can  be  designed  to  be  operated  from  space  and/or  ground,  with  the 
use  of  onboard/ground  crews  or  a customer  supplied  onboard  payload  specialist, 
and  from  the  customer's  own  facility  or  an  SSIS  facility. 

4.2.5  Ancillary  Data 

Two  options  are  available  for  obtaining  time  stamped  ancillary  data:  it  can 

be  provided  onboard  for  real  time  merge  by  the  customer,  or  in  non-real  time 
on  the  ground  via  electronic  access  to  data  archives. 

4.2.6  Command  Sequencing 

lhe  command  and  control  program  for  a payload  may  be  stored  in  an  onboard  SSDS 
mass  store,  uplinked  in  real  time  for  interactive  operations,  or  embedded  in 
the  customer's  supplied  payload  controller. 
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4.2.7 


Payload  Activation 


Activation  of  a payload  can  be  schedule  driven  with  near— realtime  adjustments 
to  the  schedule,  event  driven  for  acquisition  of  targets  of  opportunity,  or  on 
demand  subject  to  availability  of  resources  and  checks  for  cross— interference 
with  other  payloads  and  restricted  modes  of  operation. 

4.2.8  Space/Ground  Communication 

Space/ground  communications  can  utilize  the  standard  TDRSS/TDAS  (a  scheduled 
resource)  or  the  customer  can  supply  his  own  space/ground  communication  link 
(which  will  also  be  scheduled  as  a power  consuming  device  and  checked  for 
cross-interference) . 

4.2.9  Time  Management 

The  customer  may  provide  his  own  time  reference  system  or  use  the  SSDS 
supplied  reference  which  has  an  accuracy  of  +1  msec.  Since  this  reference  is 
distributed  via  the  LAN  the  customer  will  also  be  required  to  understand  the 
statistics  associated  with  delays  in  receiving  this  time  reference.  The 
reference  may  contain  ephemeris  time  plus  offsets  to  other  references  (i.e., 
universal  time)  and  will  be  formatted  per  CCSDS  requirements . 

4.2.10  Data  Transport 

Space/ground  customer-to-application  interfaces  will  utilize  the  CCSDS  packet 
formats  (slightly  modified,  as  discussed  later)  for  message  transport.  Within 
the  data  field  of  the  packet,  the  customer  can  package  his  data  using  his  own 
procedures  within  the  following  option  categories: 

1.  No  processing,  package  "raw"  data 

2.  Signal  processed/reduced 

3;  Compressed 
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4.  Encrypted  with  own  key 

5.  Error  protected  beyond  the  standard  SSDS  10~6  BER 

6.  Real-time  merge  of  SSDS  supplied  ancillary  data 

He  may  also  elect  to  package  the  data  using  an  "open"  format  specified,  for 
example,  by  a CCSDS  Standard  Format  Data  Unit  (SFDU)  or  keep  the  format 
"closed"  and  private  to  himself. 

4.2.11  Production  Data  Transport 

Production  data  delivery  can  be  real-time,  or  delayed  by  seconds,  minutes, 

. . . , next  orbit,  next  shuttle  visit,  depending  on  priorities  and  other 
factors.  An  end-to-end  BER  of  10~6  shall  be  provided  by  the  SSDS. 

4.2.12  Ground  Processing  of  Production  Data 

Standard  ground  processing  of  production  data  will  be  to  Level  0 and  with 
added  cost,  to  Level  1A. 

4.2.13  Archiving 

Standard  short  term  ground  archiving  is  for  one  week  after  receipt  of  customer 
quality  acceptance,  and  for  Level  0 data  and  Level  1A  (if  specified  per 
paragraph  4.2.12). 

4.2.14  Logistics  (SSIS) 

Standard  card  set  modules  will  be  stored  onboard  and  available  (on  a priority 
basis  as  established  by  function  criticality)  for  maintaining  payloads,  via 
automated  diagnostics,  or  interaction  with  trained  crew  person  or  a payload 

specialist.  Customers  can  elect  to  1)  have  a sealed  payload  package  with  no 

* 

intention  of  onboard  servicing,  2)  provide  spare  modules  and  crew  maintenance 
training  or  a payload  specialist. 


4-25 


4.2.15> 


Standard  Programs 


I ho  customer  will  be  able  to  use  standard  library  programs  which  can  be  linked 
into  his  programs  by  referencing  these  library  programs.  Examples  could  be: 
Fast  Fourier  Transform,  digital  filters,  Kalman  filter,  eigenvalue  and 
eigenvector  extraction,  quaternion  routines  (multiply,  vector  transformation, 
euler  angle  extraction). 

4.2.16  Data  Base  Support  Programs 

A data  base  capability  is  provided  as  an  option  to  the  customer.  This 
capability  includes  sequential  data  file  management  and  a data  base  query 
language.  Although  the  data  base  structure  is  hidden  from  the  customer,  he 
will  have  to  be  familiar  with  the  data  base  command  interface  when  building 
application  software  to  store  and  subsequently  retrieve  data  blocks  for 
manipulation  or  transmission  to  a ground  site  (delayed  delivery). 

4.2.17  Customer  Program  Development 


The  customer  will  develop  the  payload  applications  software  and  SSE  facilities 
are  available  as  an  option  to  accomplish  this.  The  customer  can  be  resident 
at  this  facility  or  these  facilities  may  be  linked  to  remote  sites  so  the 
customer  can  develop  programs  from  the  customer's  site  with  customer  supplied 
terminals  or  the  customer  may  subcontract  for  software  development  to  a 
programming  organization.  In  the  following  subparagraph  the  term  "customer" 
refers  to  whomever  is  developing  the  customer  software. 

4.2.17.1  Development  Support  Environment 


I he  customer  is  provided  with  numerous  options  within  the  software  development 
support  environment;  these  include: 

a)  Data  set  creation/storage  capability  for  source  programs  and  data 

b)  Security  of  programs  (access  control) 
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c)  Editor  to  modify  and  update  source  code 

d)  Compiler  to  convert  to  object  code  of  target  processor 

e)  Linker  to  integrate  program  into  processor  load  module 

f)  Simulation  environment  to  verify  system  integration 

g)  Standard  library  program  which  can  be  linked  to  customer  programs 

Special  customer  supplied  models  can  be  integrated  into  the  simulation 
environment . 

4.2.17.2  Development  Language 

The  development  support  environment  will  support  commonly  used  development 
languages  such  as  PASCAL  and  also  real  time  languages  such  as  Ada  (Ada  is  a 
registered  trademark  of  the  US  Department  of  Defense,  Ada  Joint  Program 
Office).  A high  order  command  and  control  language  for  developing  test  and 
control  sequences  will  also  be  available. 

4.2.17.3  System  Executive 

If  the  customer  elects  to  only  supply  application  programs  to  be  executed  in 
an  SDP , then  his  programs  will  have  to  be  integrated  into  an  executive 
structure  and  an  understanding  of  this  structure  by  the  customer  will  be 
necessary.  Included  here  are  the  techniques  for: 

a)  Creating  tasks 

b)  Activating  a system  task  (control  segment)  which  controls  the 
scheduling  of  aplication  tasks. 

c)  Real-time  control  such  as:  events,  messages,  semaphores 

d)  Local  I/O  control 

e)  Access  to  distributed  resources  (mass  store,  workstation,...) 
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The  customer  will  be  required  to  become  familiar  with  the  real-time  features 
of  the  language;  since  these  include  macros  that  interface  with  the  system 
executive.  A specification  describing  these  features  will  be  available  to  the 
customer . 

4.2.18  Onboard  Data  Processing  Resources 

Ihe  customer  may  elect  to  use  a standard  onboard  data  processor,  mass  memory 
and  workstation  or  he  may  elect  to  provide  almost  all  of  the  processing 
resources.  These  options  were  discussed  previously,  in  paragraph  4.1.3. 

4 • 3 Data  and  Command  Transport  Services 

I his  section  discusses  end— to— end  data  and  command  transport  services  in  terms 
of  a standards  model  that  illustrates  the  protocols  used  and  the  degree  of 
standardization,  compatibility,  and  commonality  that  should  be  realizeable  in 
the  SSPEs  and  SSDS. 


Emphasis  will  be  on  the  use  of  international  standards,  specifically,  the 
Consultive  Committee  for  Space  Data  Systems  (CCSDS)  Recommendations  for  Space 
System  Standards,  the  International  Standards  Organization's  (ISO)  Open  System 
Interconnect  (OSI)  seven-layer  reference  model  and  emerging  (international  and 
national)  specifications  for  the  various  layers,  being  developed  by  the 
Institute  of  Electrical  and  Electronic  Engineers  (IEEE),  the  American  National 
Standards  Institute  (ANSI),  National  Bureau  of  Standards  (NBS),  European 
Computer  Manufacturers  Association  (ECMA) , and  others. 

The  end-to-end  operations  perspective  encompasses  the  following  physical  nodal 
extremes:  core  subsystems  and  payload  packages  integrated  via  point-to-point 

links  and  the  onboard  local  area  networks  (LANs)  in  the  various  SSPEs, 
space/ground  communications  and  the  use  of  special  TDRSS  uplink/downlink 
protocols,  and  the  ground— to— ground  world— wide  area  communications  network. 

The  wide  area  network  includes  long  haul  communications  that  interconnects 
ground-based  local  area  networks  and  end-point  nodes. 


Ihe  SSDS  network  has  unique  characteristics,  as  compared  with  public  and  other 
data  networks,  including: 
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• significant  control  by  NASA, 

• the  use  of  high  level  coding  such  as  Reed-Solomon  to  guard  against 
errors, 

• transport  of  both  interactive  (realtime)  and  non-interactive 
messages, 

• functions  such  as  data  capture  which  support  recovery  of  lost 
application  data, 

• data  that  is  transported  through  the  network  that  can  be 
interpreted  as  commands  and,  hence,  must  be  checked,  in  some 
instances  in  realtime,  for  restrictions  and  constraints  (payload 
cross-interference) , 

• high-  and  low-rate  quick-look  and  production  data, 

• image  and  non-image  data  and  in  both  realtime  and  (delayed) 
non-realtime,  and 

• commercial  quality  imagery,  low-resolution,  f reeze-frame,  and  high 
resolution  TV. 

A preliminary  configurations  for  the  onboard  data  system  is  given  in  Figure 
4.3-1,  and  the  variety  of  data  types  that  must  be  transported  through  the  SSDS 
are  functionally  shown  in  Figure  4.3-2,  with  an  important  subset  of  these 
types  also  characterized  and  presented  earlier  in  Figure  4. 1.3-4  in  terms  of 
data  volume,  delay  and  reliability  requirements,  and  the  range  of  transport 
services  that  will  be  required. 

The  onboard  data  network  model  shown  in  Figure  4.3-1  is  comprised  of  a series 
of  LANs  dedicated  to  modules  but  with  a backbone  interconnecting  the  module 
LANs  via  bridges.  Specific  points  to  be  made  are  that: 
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Figure  4.3-1.  Onboard  Data  System 
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Figure  4.3-2.  SSDS  Message  Types 
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1.  TV/audio  has  it  own  distribution  subnetwork  and  is  isolated  from 
the  LANs. 

2 High  rate  payloads  have  dedicated  point-to-point  data  links  with 
the  communication  and  tracking  subsystem  (gateway  to  earth  station). 

3 Data  transport  for  low  rate  payloads,  core  subsystems,  and  control 
of  high  rate  payloads  is  implemented  using  the  LANs. 

4 All  units  interfacing  with  the  LAN  have  a Network  Interface  Unit 
(NIU)  which  implements  the  lower  layers  of  the  distributed 
operating  system. 

4.3.1  On  the  Use  of  International  Computer  Networking  Standards 

The  CCSDS  telecommand  (TC)  and  telemetry  (TM)  packet  standards  are  documented 
in  References  2 to  12  and  are  in  various  stages  of  being  ratified  as 
international  standards.  In  the  end-to-end  space-to— space  and  space -to-ground 
flow  developed  herein,  the  customer/operator  interfaces  with  the  SSDS  is  at 
the  top  layer  of  the  CCSDS  model  (TM/TC  Packets)  as  shown  in  Figure  4.3. 1—1. 

The  key  points  to  be  noted  in  this  figure  are  as  follows: 

1.  Customer/operator  generates  telecommand  (TC)  packets,  either 
onboard  or  ground,  which  are  transparent ly  delivered  to  his 
application  on  the  SS/POP  or  via  the  SS,  routed  to  the  COP,  or  to 
ground  components . 

2.  Onboard  the  SS,  POP  or  COP,  the  customer's  equipment  (or  core 
subsystems)  generate  telemetry  (TM)  packets  which  are  delivered  to 
ground  facilities  designated  by  him  (his  own  facilities,  POCG,  RDC , 
CC,  ,..).  TM  packets  can  also  originate  on  ground  and  be  delivered 
to  a space  application. 

3.  In  all  cases,  the  complexities  of  the  data  distribution  network  are 
transparent  to  the  customer. 
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Figure  4.3. 1-1.  CCSDS  Telemetry  and  Telecommand  (End-to-End) 


4.  The  TC  and  TM  packets  must  conform  to  the  CCSDS  formats  including 
primary/secondary  headers,  max  packet  size,  .... 

5.  TM  and  TC  packets  are  bidirectional,  e.g.,  TM  or  TC  packets  can  be 
generated  onboard/ground  and  transmitted  to  ground/onboard . 

The  three  layer  CCSDS  model  is  characterized  as  follows: 

1.  The  upper  layer  (telemetry/telecommand  packet  layer)  is  intended 
for  customer/operator  interfaces  as  described  above,  for  data  to  be 
transported  between  space  and  ground. 

2.  The  lower  two  layers  are  intended  for  use  in  noisy  space  data 

links:  space-to-ground , ground-to-space  and  space-to -space . 
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To  provide  for  complete  automated  internetworking  in  a heterogeneous 
environment,  additional  capabilities  are  required  which  can  be  found  in  the 
International  Standards  Organizations  (ISO)  Open  System  Interconnect  (OSI) 
seven  layer  reference  model.  The  functions  of  the  OSI  layers  are  summarized 
in  Figure  4.3. 1-2,  and  draft  proposals  associated  with  these  layers  are  also 
in  various  stages  of  being  ratified  as  international  standards  (see,  for 
example,  reference  13). 


APPLICATION  LAYER 

Common  Appttcatkm>S*rvic«  Elements  (CASE) 

Log-in 

Password  checks 

Sets  up  associations  to  named  peers  and  agreement  on  the 
semantics  of  the  information  to  be  exchanged 
Commitment,  concurrency,  and  recovery 
Specific  Application-Service  Elements  (SASE) 

File  transfer,  access,  and  management 
Basic-class  virtual  terminal 
Forms-class  virtual  terminal 
Message  handling 
Document  transfer 
Job  transfer  and  manipulation 
Videotex,  teletex,  telefax 
Graphics  (semantics) 

Data  base  access  and  transfer 
Directory  service 


System  management 

Purchase  orders 
Banking  protocols 
Credit-checking  protocols 
invoice  protocols 
Inventory  protocols 


Industry  protocols 
(Developed  by  special- 
interest  groups) 


Dialog  control  (who  speaks,  when,  how  long,  half-  or  full-duplex) 
Synchronization  between  end-user  tasks 
Graceful  and  abrupt  closure 

TRANSPORT  LAYER 

Reliable  end-to-end  bit  pipes  (transport  connections) 

Multiplex  end-user  addresses  onto  network 
End-to-end  error  detection  and  recovery 
Flow  control 

Monitoring  quality  of  service 

Possibly  disassembles  and  reassembles  session  messages 

NETWORK  LAYER 

Sets  up  routes  for  packets  to  travel  (establishes  a virtual  circuit) 
Addresses  network  machines  on  the  route  through  which  the  packets 
travel 

May  disassemble  transport  messages  into  packets  and  reassemble 
them  at  the  destination 

Sends  control  messages  to  peer  layers  about  own  status 
Congestion  control  (regulates  flooding  within  the  network) 
Recognizes  message  priorities  and  sends  messages  in  proper  order 
Internetworking  (both  connection-oriented  and  connectionless) 


PRESENTATION  LAYER 

Negotiates  concrete  transfer  syntax  (bit-encodings)  for  character 
sets,  text  strings,  and  other  data  types  to  be  exchanged 
Session  services  pass-through  (passing  Session  services  to  the 
Application  layer  after  transfer  syntax  is  negotiated) 


DATA-LINK  LAYER 

Reliable  transfer  of  data  across  a single  link 

Adds  flags  to  indicate  beginnings  and  ends  of  messages 

Adds  error-checking  algorithms 

Makes  sure  data  are  not  mistaken  for  flags  (transparency  mechanism) 
Provides  access  methods  for  local-area  networks 


SESSION  LAYER 

Maps  addresses  to  names  (users  retain  same  name  if  they  move) 
Connection  establishment  and  termination 
Data  transfer 


PHYSICAL  LAYER 

Handles  voltages  and  electrical  pulses 

Handles  cables,  connectors,  and  components  (interfaces  to  media) 
Handles  collision  detection  for  CSMA/CD  access  method 


TAKEN  FROM  SYSTEMS  & SOFTWARE,  MARCH  1985 
Figure  4.3. 1-2.  Functions  of  the  OSI  Layers 


In  the  development  herein  the  position  taken  is  that  the  lower  two  CCSDS 
layers  provide  the  space  transport  services  required  in  the  lower  two  layers 
of  the  OSI  model  (i.e.,  data  link  layer  and  physical  layer)  and  the  upper- 
layer  IM/IC  packets  are  transported  to/from  the  customer  using  interprocess 
message  tranfer  services  in  the  OSI  application  layer. 

Figure  4 . 3 . 1-3  shows  a bidirectional  space  to  ground  packet  flow  with  the 
CCSDS  packets  originating  as  a service  in  layer  7,  and  using  layers  1-4  for 
LAN  transport  services  to  the  communication  gateway  where  CCSDS  packets  are 
then  recovered  and  embedded  in  the  CCSDS  lower  two  layers  for  transport  to 
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ground  (space).  In  the  ground  (space)  segment,  the  lower  two  CCSDS  layers  are 
removed,  the  TM/TC  packets  are  recovered  and  ISO  services  are  then  used  again 
for  data  transport  to/from  the  ground  terminal  node. 


Space  Ground 


Figure  4.3.1 -3.  CCSDS  Packets  Standard  in  ISO  Upper  Layer  Logical  View 


4.3. 1.1  Onboard  SSDS  Interfaces 

A generalized  interface  diagram  is  given  in  Figure  4.3. 1.1-1  that  shows  the 
end-to-end  interface  options  in  a reference  model  configuration  combining  the 
ISO  and  CCSDS  layered  models.  The  interpretation  to  be  given  to  the  diagram 
is  that  data  originating  in  the  payload  traverses  a thread  that  goes  from 
Layer  7 to  Layer  1 on  the  LAIM  (exits  the  payload  NIU)  back  up  to  Layer  7 
(through  the  NIU  in  the  communication  gateway)  down  to  CCSDS  Layer  1 (exits 
the  SS  antenna)  up  to  Layer  2 (frame  processing  in  the  earth  station)  up  to 
Layer  7 where  the  packets  are  recovered  for  transport  as  an  OSI  message,  down 
to  Layer  1 to  enter  the  WAN  medium  and  then  back  up  to  the  application  layer 
for  final  delivery  to  the  ground  customer.  Various  other  end-to-end  threads 
could  also  be  developed  in  a similar  manner  for  cases  of  internetworking, 
circuit  switched  networks,  ...,  but  are  not  included  here.  Other  points  to  be 
noted  are  as  follows: 
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Figure  4.3.1. 1-1.  Onboard  Interfaces  to  SSDS 


1.  Standard  message  protocols  are  shown  at  the  application  layer  which 
would  be  defined  by  HOL  record  type  or  SFDU  data  type 
declarations.  CCSDS  TM/TC  types  would  be  transported  through  the 
space  ground  medium  and  the  others  would  be  transported  onboard. 

2.  Representative  onboard  and  ground  LAW  and  WAN  options  for  the  lower 
two  layers  are  identified. 

3.  The  SSDS  Time  Management  function  provides  time  to  the  payload  with 
an  accuracy  of  + 1 msec  in  one  of  the  CCSDS  standard  formats. 

4.  A network  management  function  resides  at  the  application  layer 
gathering  data/statistics  from  the  lower  layers  and  reporting  these 
to  the  network  manager. 

5.  The  user  interface  at  the  application  layer  is  further  expanded  in 
Figure  4.3.1. 1-2 
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4. 3. 1.2  Ancillary  Data 

A representative  set  of  ancillary  data  is  shown  in  Figure  4.3. 1.2-1  and  its 
size  is  estimated  to  be  512  bytes.  At  this  time  the  preferred  distribution 
approach  would  be  to  allocate  these  parameters  to  three  groups  (State, 
Activities,  and  Environment)  and  to  multicast  the  groups  to  the  appropriate 
payloads.  The  components  in  each  group  would  “slowly"  change  based  on  payload 
changeout . 

4.3.  1.3  Global  Addressing:  Physical,  Object  IMame,  Application  Process  ID 

and  Spacecraft  ID 
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DATA  TYPES 


Time 

Configuration  Changes 
Attitude 
Orbit  Position 
Water  Dump  Status 
Pointing/Orientation 
Power  Fiux/Usage 
EMI  Map  of  Station 
Thruster  Firings 
Internal  Pressure 
Atmosphere  Composition 
Relative  Humidity 


DISTRIBUTION  OPTIONS 

■ Payloads  Poll  for  Data 

■ Broadcast  Every  TBD  msec  Using  Dynamically  Changing  “Standard” Package(s) 

■ Combination  of  Broadcast/Poll 

SIZE 

Estimated  To  Be  512  Bytes 
OTHER 

Use  “Open”  Format  for  Data  (i.e.,  SFDU) 


Radioactivity  Exposure 
Chemical  Contaminants 
Optical  Environment  Contaminants 
Crew/Operations  Activity 
Accelerometer  Data 
OMV  Berthings/Status 
EVA  Activity 
Internal  Temperature 
External  Temperature 
Particulate  Count 
Particulate  Types 
• 


Figure  4.3.1. 2-1.  Ancillary  Data 


Server  Name  and  Physical  Address 


In  a distributed  computer  network,  nodes  are  entities  that  may  have  resources 
that  can  be  globally  addressed  as  object  names  remotely  from  other  nodes. 

Some  examples  of  distributed  entities  are  printers,  files,  remote  jobs, 
terminals,  peripheral  devices,  payloads  and  core  subsystems.  A service  is 
implemented  by  a process  called  a server  who  provides  requested  services  to 
authorized  customers.  An  example  is  a file  server,  printer  server,  or  payload 
data  server  whose  logical,  or  object  address,  is  a character  string  (a  name). 
One  implementation  of  the  server  concept  is  to  have  each  object  (MTU ) LISTEN 
for  its  (layer  4)  transport  (phy sical/NIU)  address;  to  use  a server  a customer 
requests  a CONNECT  specifying  the  appropriate  server  address.  The  problem  for 
the  customer  is  to  determine  which  object  is  listening  to  which  transport 
address?  The  customer  will  want  to  request  a service  by  NAME,  which  is 
generally  a character  string  intended  for  use  by  operators  rather  than 
machines  (NIUs  respond  to  binary-encoded  physical  addresses).  To  obtain  the 
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NAME: ADDRESS  mapping  a DIRECTORY  SERVICE  whose  address  is  well  known  and  never 
changes  is  consulted  and  the  global  physical  address  is  received;  this 
sequence  is  all  transparent  to  the  customer. 

CCSDS  Addressing  Structure 

The  CCSDS  packet  and  transfer  frame  ID/addressing  structures  are  summarized  as 
follows : 

SPACECRAFT/APPLICATION  ADDRESS  FIELD 


Spacecraft  (SSPE)  ID  (Transfer  Frame  Protocol)  10  Bits 

used  for  routing  in  space-to-space 

Telemetry  ID  (Source  ID  within  one  SSPE)  11  Bits 

Telecommand  ID  (Destination  ID  within  one  SSPE)  11  Bits 


Spacecraft  ID  is  assigned  by  the  CCSDS  international  organization  and  an 
example  of  routing  data  using  the  spacecraft  ID  is  shown  in  Figure  4.3. 1.3-1 
(the  case  is  for  earth  to  COP  via  Space  Station). 

The  CCSDS  packet  format  for  TM  and  TC  is  shown  in  Figure  4.3. 1.3-2  and 
includes  an  11  bit  Application  Process  ID  addressing  field  that  is  assigned  by 
the  program  office  for  each  SSPE  and  which  is  logically  equivalent  to  the 
OBJECT  NAME  entity  previously  discussed  (i.e.,  a logical  address).  The  10  bit 
SSPE  address  and  11  bit  Application  ID  assignment  concept  is  illustrated  in 
Figure  4.3. 1.3-3. 

End— to-End  Addressing 

With  respect  to  the  end-to-end  SSDS  design^shown  in  Figure  4.3. 1.3-4,  messages 
are  transported  onboard  the  SS  within  an  OSI  environment,  and  on  ground  within 
an  OSI  environment,  between  elements  that  have  unique  physical  addresses. 

When  leaving  the  space  or  ground  OSI  environment  (i.e.,  space-to-ground,  or 
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Figure  4.3. 1.3-1.  Space-to-Space  Routing  Example 


■ For  Bidirectional  TM/TC  Packet  Concept 

■ Single  Packet  Type  Designated  for  TM  or  TC 

■ Global  Application  Process  ID  (Logical  Address)  Maps  to 
Physical  Address(es)  at  Session  Establishment  Time 


Packet  Type 


ID  Function 


1 = Telemetry  Packet 

Source  of  Packet  (On  Board  or  Ground) 

0 = Telecommand  Packet 

Destination  of  Packet  (On  Board  or  Ground) 

Figure  4.3. 1.3-2.  CCSDS  Packet  Format  (Revised) 
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SSPE,  ( pop 


SSPE.  COP 


TM/TC  Packets 


TM/TC  Packets 


— * Application  ID 

Function  No. 

SAAX0021.INSTDAT  1 
SAAX0021 . ANCD  AT  2 


TM  Packets 
(Source  ID) 

TC  Packets 
(Destination  ID) 


Ground  Element 

Application  ID 
Function  No. 

COMM1020.POCC.XXX  j+1 
COMM1020.POCC.YYY  j+2 
COMM1020.POCC.ZZZ  j+3 


Ground 
■ Elements 
(GEs) 


Figure  4.3.1. 3-3.  CCSDS  Mapping/ Assignment  Space 


Peer-to-Peer 
Bidirectional  Processes 


TC  Packet 


Space 

Station 

Program 

Element 

OSI 

Environment 


TC  Packet 


Transport  of 
CCSDS  TM/TC 
Packets 


Transfer 

Frame 


Interprocess 

Messages 


Ground 

OSI 

Environment 


Interprocess 

Messages 


Sessions  are  established  by  onboard  facility  management  function  on 
request  from  user  and  coordinated  with  scheduler  and  resource 
management  functions. 


Figure  4.3.1. 3-4.  End-to-End  SSDS  Design  Concept 
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space-to-space  transport),  TM  or  TC  packets  are  transported  from/to 
Application  Process  IDs  which  are  also  unique  and  which  map  to  a unique 
physical  address.  Application  IDs,  like  OBJECT  NAMES,  in  general  can  be 
relocated  to  different  physical  (NIU)  addresses  and  the  mapping  at  the  two 
nodes  on  each  end  of  the  layer  2 space— to— ground  data  link  must  be  determined 
(via  the  DIRECTORY  SERVICE)  at  session  establishment  time,  or  the  routing 
algorithm  can  use  tables  that  are  preset  by  the  network  management  function  to 
accommodate  a slowly  changing  network  topology. 

End-to-End  Routing 


At  session  establishment  time  communication  resources  including  data  paths 
through  the  network  will  be  bound  for  the  term  of  the  session  (realtime 
dynamic  routing  through  a ground  packet  switched  network  is  not  precluded, 
however) . 

Figure  4 . 3 . 1 . 3-5  demonstrates  the  ISO/OSI  and  CCSDS  protocols  used  on  an 
end-to-end  basis  showing  communication  within  a space  or  ground  OSI 
environment  and  through  space  in  a CCSDS  environment.  For  a connection 
(non-datagram)  service  the  end-to-end  connection  options  are  shown  in  Figure 
4 . 3 . 1 . 3-6 . An  example  of  the  mapping  concept  required  in  the  onboard  C&T 
gateway  to  deliver  a customer  packet  from  his  ground  operation  center  to  his 
onboard  application  is  given  in  Figure  4.3. 1.3-7. 

4.3. 1.4  Onboard  User  Interfaces  and  Data  Delivery  to  Ground 

As  stated  earlier,  the  customers  principle  SSDS  interface  for  message 
transport  through  space  is  the  CCSDS  packet  and  for  transport  within  space  or 
within  ground  the  data  is  transported  in  standard  interprocess  messages. 
Another  item  also  discussed  was  data  transport  transparency , on  an  end-to-end 
basis,  to  the  customer.  These  two  elements  will  be  demonstrated  later  using  a 
hypothetical  payload  and  showing  the  important  interfaces  that  transport  the 
data  through  the  distribution  network. 
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Figure  4.3.1. 3-5.  End-to-End  Protocols 


Space -j- — -[- Ground 


Application 

Presentation 

Session 
Transport 
Network 
Data  Link 


Terminal  Terminal 


Figure  4.3. 1.3-6.  End-to-End  Connection  Diagram 
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Figure  4.3.1 .3-7.  End-to-End  Packet  Delivery  (Example) 


Core/Payload  Telemetry  Interface 

Figure  4.3. 1.4-1  shows  the  CCSDS  packet  that  will  be  used  as  the  payload's 
data  carrier  through  the  space  network.  The  details  of  using  this  message 
structure  are  given  in  references  2-12  and  only  the  boxes  in  the  diagram  will 
be  discussed  here.  Source  Data  and  Secondary  Header  fields  are  delineated  in 
the  packet  structure;  the  customer/customer  packages  data  into  the  primary 
Source  Data  field  using  the  indicated  options.  Associated  with  data  in  the 
primary  field,  the  customer  may  elect  to  use  the  secondary  field  to  package 
ancillary  data,  time,  various  flag  designations,  and  other  parameters. 
Alternately,  he  may  elect  to  embed  these  secondary  data  items  in  the  primary 
field  with  a unique  Application  Process  ID.  The  SSDS  has  a requirement  to 
transport  this  message  to  the  ground  customer  (possibly  delayed  in  which  case 
it  is  stored  prior  to  transmission)  with  an  end-to-end  bit  error  rate  (BER)  of 
less  than  10  6.  The  customer  has  several  options  to  improve  this  BER  as 
shown  below: 
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Figure  4.3.1. 4-1.  Core/Payload  Telemetry  Interface 


1.  At  session  establishment  time,  specify  quality  of  transport  service 
desired  at  ISO  layer  4 and  CCSDS  layer  2. 

2.  Specify  forward  error  correction  in  CCSDS  layer  2 (i.e., 
Reed-Solomon  encoding  with  parameters  255,223)  or  encode  the  data 
using  his  own  algorithm  prior  to  inserting  the  data  into  the  source 
data  field. 

3.  Use  the  two  byte  Packet  Error  Control  field  (e.g.,  compute  a 16  bit 
CRC  for  the  entire  message  and  use  for  error  detection  requesting 
retransmission  at  the  application  layer). 

Lost  and  Out-of-Sequence  Packets 

As  CCSDS  data  packets  (or  segments  of  CCSDS  packets)  are  transported  from 
their  point  of  origin  (e.g.,  a command  from  a workstation  in  a POCC  or  data 
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from  an  A/D  converter/formatter)  to  their  final  destination  (end-to-end 
transport)  they  can  be  transformed  enroute  in  many  ways: 

1.  They  can  become  corrupted  by  noise-induced  bit-reversals  so  that 
the  data  delivered  is  not  identical  to  the  data  at  the  point  of 
origin. 

2.  They  can  become  electronically  and  physically  lost  at  intermediate 
points  (nodes)  in  the  transport  chain  due  to  storage  media  overlows 
(temporary  buffers),  node  processor  failures,  communication  link 
(between  node)  failures,  and  other  reasons. 

3.  Data  packets  may  arrive  out-of-order  (out-of-sequence)  due  to  their 
transport  over  different  physical  (e.g.,  cable)  or  logical  (e.g., 
CCSDS  Virtual  Channels)  links. 

The  above  problems  are  real  ones  and  are  ones  that  are  addressed  in  commercial 
data  transport  networks  (e.g.,  TYMNET)  and  in  the  CCSDS  and  the  ISO/OSI 
standards  models.  Recall  that  layers  one,  two,  and  three  of  the  OSI  model 
form  a Network , with  possibly  multiple  end-to-end  paths  between  any  two 
connected  nodes,  and  that  layer  four,  thee  end— to— end  Transport  Layer, 
considers  the  Network  to  be  intrinsically  unreliable  (i.e.,  noisy  and  subject 
to  link  failures).  The  Transport  Layer,  guarantees  in-sequence  delivery  of 
packets  and  provides  a class  of  service  that  guarantees  error  free  data 
delivery  on  an  end-to-end  basis.  These  services  are  basically  provided  by 
incorporating  end-point  buffering  to  re-order  packets  at  the  receiving  node, 
enroute  (data  capture)  buffering  which  is  released  only  upon  positive 
acknowledgement  of  a "window"  of  data,  and  fault-tolerant  operations  to 
provide  rapid  alternatives  following  communication  processor  and  link  failures. 

The  SSDS  will  provide  the  same  class  of  service  as  above  but  the 
implementation  will  be  more  expensive  due  to  the  higher  data  rates  and  the 
larger . end-to-end  extent  of  the  SSDS.  It  is  expected  that  all  users  do  not 
require  and  do  not  want  to  pay  for  the  above  quality  of  service  and  that 
reduced  classes  of  services  (per  CCSDS  arid  the  OSI  models)  can  be  defined  with 
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corresponding  reduced  data  transport  charges.  The  extremes  in  these  services 
are  as  follows: 


1.  The  event  to  be  captured  is  short-lived,  is  an  opportunity  of  the 
century,  and  no  recapture  is  possible.  In  this  case  the  user  may 
want  data  captured  in  multiple  locations  and  will  want  the  highest 
quality  of  data  transport  services.  All  packets  will  be 
transported  to  the  terminal  node(s)  in  sequence  with  no  missing 
data  and  virtually  error  free. 

2.  The  data  is  extremely  redundant  and  updated  at  a high  rate  so  that 
the  loss  of  a single  frame  or  subframe  of  data  is  of  little 
consequence  provided  that  incomplete  frames  are  so  noted  and  that 
frames  are  delivered  in  sequence. 

In  addition  to  the  classes  of  service  specified  in  the  CCSDS  and  OSI 
standards,  the  customer  at  the  application  level  (above  layer  7)  can  do  the 
following : 

1.  He  can  encode  his  data  to  provide  for  increased  error  protection 
(forward  error  correction). 

2.  He  can  provide  his  own  buffer/store  and  use  an  erid-to-end 
application-to~application  acknowledgement  of  receipt. 

3.  He  can  specify  that  data  be  recorded  (captured)  onboard  and 
transmitted  to  ground  for  capture 

4.3.2  System  Design  for  a Hypothetical  Payload,  COM  XXXX 


Introduction 


Figure  4. 3. 2-1  shows  the  system  design  for  the  hypothetical  payload  COM  XXXX 
which  has  the  following  features  and  interface  requirements : 

• A pointing  and  tracking  system,  teleoperated  from  ground  or  onboard . 
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, a 

• An  imaging  sensor  array  of  dimension  100  x 100  (10  pixels),  a 10 

5 

bit  A/D  converter  (10  bits  per  image),  so  that  at  an  image  rate 
of  50  per  second,  the  total  image  data  rate  is  5*106  BPS. 

• Payload  performance  (engineering)  data  is  acquired  and  packaged  for 
transport. 

• The  I/O  Electronics,  Payload  Processor,  Memory  and  NIU  circuit 
assemblies  are  integrated  via  a standard  backplane  bus  (e.g.,  VME 
Bus)  . 

• The  memory  is  divided  into  several  components;  one  of  these,  as 
shown,  is  a shared  RAM  where  the  sensor  and  performance  data  is 
stored  as  directly  received  from  the  A/D  converter.  This  segment 
of  memory  is  subdivided  into  LAN  packet-sized  elements  (64  IK 
packets)  and  the  payload  processor  builds  the  CCSDS  and  OSI  headers 
and  trailers  around  the  packets  without  moving  the  data. 

• The  Time  Management  Function  provides  time  to  the  payload  via  the 
NIU  and  the  Payload  Processor  embeds  it  in  the  CCSDS  packet,  as 
required . 

• The  NIU  and  processor  implement  the  network  operating  system. 

• The  payload  communicates  with  other  LAN-connected  components  as 
shown  and  based  on  sessions  established  by  the  network  manager. 

In  this  development  the  customer  has  provided  his  own  electronics  package  but 
uses  certain  SSDS  standard  cards:  specifically  the  card  sets  for  the  SDP, 

memory,  and  the  NIU.  He  has  provided  the  custom  I/O  electronics  that  have 
unique  interfaces  to  his  instrument  (i.e.,  torque  motors,  gyros,  scan  control 
interface,  A/D  converter,  and  so  on).  The  sensor  data  can  be  displayed  on  an 
MPAC  display  at  the  same  resolution  as  the  sensor  and  by  mapping  the  pixel 
value  to  the  display's  color  code,  the  quality  of  the  data  can  be  validated 
via  quick  look  by  a pre-trained  crew  person.  (By  doing  this  the  customer  has 
provided  for  both  onboard  and  ground  operations.) 


4-47 


Instrument 


Pointing  & 
Tracking 


1,1 


s 

100,1 


ARRAY 
(XI,  Yj) 


-1,100 

j 


s 

•100,100 


Sensor 

Instrumentation 


. Torque  Motors 


Rates,  Positions 
Sensor  Out 


10«  pixels/FR 
Scan  Control 


Xi,  Yj  (i,j  = 


1 to  100) 


Sensor  Data  Rate 

• 12.5  *103  octets 
per  Frame 

• 50  FR/sec 

• 5 *10«  bps 


Engineering  Data 

<Z>  Backplane 
Bus  l/Fs 

LANI/Fs 


LAN  Medium 


I/O  Electronics 


Active 

, _ ^Control  _ _ 

' ”|C=^ 

50  Frames/sec 
Engineering 
Data 

• Temp 

• Voltage 


Payload 

Processor 


Instrument 

Controller 

• Test 

• Control 

• TM  Packet 
Build 

• TC  Packet 
Decode 

• Sensor  Data 

• Eng  Data 

• Other  Data 

IZZ3 


flimr* ’ 


Memory 
Prom  j Self 
Test,  Init, 
Boot-Up,  . . . 
RAM  I 

Operating 
Systems  (Local/ 
Dist  b)  & Appli- 
cation Programs 

Shared  RAMl 


• Comm  l/F 

• Packet 
Build 


{-►j  Management 
| Function  j 


Network 
Interface 
Unit  (NIU)| 


~r~ 

• • • 

♦ 

NIU 

NIU 

Mass  Memory 

w w 9 

MPAC 

64  Ik  Packets 
140  nsec  Cycle 
at  100  mpbs  LAN 


■f 


1 

NIU 

Ground  Interfaces 

— Telemetry 

— Telecommand 

C&T 

Onboard  interfaces 


Figure  4.3.2-1.  System  Design  for  Payload/Mission  COM  XXXX  (Example) 


The  payload  has  a duty  cycle  of  5%  so  that  pouter  is  normally  disconnected  from 
the  package.  Mhen  the  schedule  time  for  payload  activation  has  arrived  the 
following  events  occur: 

1.  Thermal  control  to  the  unit  is  activated. 

2.  Prime  power  is  applied  and  sensed  for  abnormal  current. 

3.  The  payload  processor  is  reset  to  the  POWER  ON  state  by  an  internal 
power  on  discrete. 

4.  In  the  POWER  ON  state  the  processors  program  counter  is  reset  to  memory 
location  zero,  the  location  of  the  PROM-embedded  self-test  routine, 
delf-test  is  then  initiated  and  the  results  are  stored. 

5.  The  NIU  then  performs  a self-initialization  procedure  to  become  an 
addressable  LAN  entity  using  procedures  such  as  can  be  found  in 
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IEEE  Standard  802.5  paragraph  4.2.3,  entitled  Standby  Monitor 
Finite-State  Machine. 

6.  Sessions  between  the  payload  and  other  devices  assigned  by  the 
schedule  function,  are  now  established  by  the  network  manager. 

This  assures  that  all  resources  are  communicating  that  are  required 
to  support  the  session. 

7.  Wumerous  scenarios  are  now  possible  for  payload  operations: 

• Autonomous  payload  operation  vs  step-by-step  operator 
direction . 

• Quick  look  mode  via  onboard  or  ground  operations  followed  by 
a production  mode  with  data  stored  onboard  or  transmitted  to 
ground . 

• Interactive  operations  in  a browse  mode  (quick  look)  followed 
by  an  automated  inertial  track  mode  (production  data 
acquisition)  followed  by  repeats  of  this  cycle  throughout  the 
whole  session. 

The  processor  could  have  had  the  command  sequences  (program)  stored  in  PROM, 
booted  from  mass  store,  or  provided  from  ground.  The  processor  application 
functions  include  mode  control,  test,  TC  packet  decode,  TM  packet  build  for 
sensor  and  performance  data,  ancillary  data  extract  and  merge,  teleoperate 
interface  for  instrument  pointing,  instrument  auto-track,  and  so  forth. 

When  the  session  schedule  expiration  nears,  the  session  entities  will  be 
notified,  allowing  for  an  orderly  disconnect:  the  processor  will  secure  the 

instrument,  and  the  core  subsystem  manager  for  power  and  thermal  will 
disconnect  their  services  in  a sequence  that  provides  thermal  protection 
against  an  over-temp  condition. 
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COM  XXX  TM  Packet  Flow  - End-to-End 


End-to-end  TM  packet  flow  for  COM  XXXX  is  shown  in  three  parts  in  Figure 
4. 3. 2-2.  This  flow  is  based  on  the  functionality  previously  described  and 
illustrates  the  protocols  used  in  the  end-to-end  data  transport.  The 
discussion  herein  will  be  based  solely  on  this  three-part  figure. 
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Figure  4.3.2-2.  End-to-End  TM  Packet  Flow  (1  of  3) 


This  scenario  shows  one  message  type  (the  TM  packet)  being  built  and 
transported  through  the  C&T  mode  to  the  ground  terminal  node.  Telecommands 
would  traverse  the  opposite  path  and  the  processor  would  have  the  "opposite" 
function  of  interpreting  the  contents  of  the  command  packet.  Likewise,  other- 
message  types  from  onboard  entities  would  be  built  for  transmission  and 
received  messages  would  be  interpreted  based  on  a message-type  label. 

In  the  first  figure  (1  of  3)  the  TM  packet  is  being  built  using  one  image  scan 
(12.5*10  octets)  per  packet  and  the  processor  packages  other  data 
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(ancillary,  performance,  time.  ...)  into  the  secondary  header  (an  alternative 
would  be  to  create  individual  packets  for  secondary  data).  The  maximum  packet 
size  (2  -1  octets)  easily  accommodates  the  data.  Packet  segmentation,  a 

flow  control  mechanism,  is  not  required  since  the  NOS  at  layer  4 will  segment 
"large"  messages  prior  to  transmission  on  the  LAN.  In  this  example  the 
customer  has  elected  to  add  the  two  (optional)  Error  Packet  Control  octets 
which  he  will  interpret  (error  detection  with/without  correction)  when  the 
packet  is  delivered  to  him. 

The  NOS  implements  services  and  primitives  associated  with  the  seven  layer 
model  shown  in  the  first  figure.  For  this  payload,  connections  would  be 
established  at  the  top  four  layers  and  Class  2 services  would  be  specified  at 
layer  4.  In  this  case  the  Common  Application  Service  Element  (CASE)  provides 
a message  service  for  the  indicated  50  packets  per  second  to  be  transported  to 
the  C&T  node.  Layer  3 disassembles  the  13K  octet  packet  (message)  into  14  LAN 
packets,  adds  two  routing  headers  (possibly  null  if  bridges  are  not  involved) 
and  layer  2 frames  the  data  for  transmission  by  adding  the  layer  2 header  and 
trailer.  The  trailer  is  a CRC  code  used  for  error  detection  at  the  receiving 
node,  and  the  header  includes  the  address  of  the  C&T  node.  If  a token  ring  is 
assumed,  and  for  this  example  a 1 Kbyte  LAN  packet  is  assumed,  then  14  token 
acquisitions  will  be  required  to  transport  this  image-frame  of  data  to  the  C&f 
node . 

Part  2 of  the  figure  shows  the  seven  layer  processing  at  the  C&T  node  to 
recover  the  COM  XXXX  TM  packet;  the  C&T  is  also  receiving  packets  fom  other 
sources  (layer  2 LAN  packets  and  TM/TC  packets  from  the  high  rate  payloads  via 
point— to— point  links).  Additionally,  TV  and  audio  is  being  received  from  the 
TV/Audio  subnet  and  being  digitized  and  compressed.  All  of  these  data  are 
being  segmented  (if  required)  and  installed  into  CCSDS  Transfer  Frames  for 
space  transport  to  earth.  A virtual  channel  concept  is  employed  to 
time-divide  the  TDRSS  bandwidth  to  implement  flow  control  ("link  hogging")  and 
to  provide  timely  access  to  the  channel  for  realtime  data  like  TV  and  audio. 
The  output  of  the  virtual  channel  multiplexer  (itself  a virtual  device)  is 
serialized  and  Reed-Solomon  encoded  (an  option  exercised  at  session 
establishment  time)  and  then  interleaved  prior  to  entering  the  modulator  and 
RF  section  of  the  C&T. 
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Figure  4.3.2-2.  End-to-End  TM  Packet  Flow  (2  of  3) 


In  part  three  of  the  figure,  the  transfer  frames  are  recovered  in  the  receiver 
as  they  enter  the  Data  Handling  Center  for  routing  to  their  ultimate 
destination.  At  this  point  the  data  (TV,  voice,  TM/TC  packets)  are  embedded 
in  transfer  frames.  When  Reed-Solomon  Sync  Codes  are  detected,  real  time  R-S 
decode  and  error  correction  is  performed  prior  to  frame  processing. 
Uncorrectable  errors  would  be  flagged,  and  in  the  event  that  a 
connection-oriented  service  was  in  effect  for  the  session  associated  with  the 
frame,  then  a retransmission  of  the  frame  would  be  requested  (i.e.,  this  is  in 
the  case  that  a TC  packet  was  transmitted  from  space  — recall  that  in  the 
CCSDS  1C  concept,  retransmission  is  mandatory  when  a TC  error  is  detected  and 
not  correctable.  In  the  MDAC  concept,  Reed-Solomon  coding  has  been 
substituted  for  the  Hamming  code  normally  used  for  TCs).  The  transfer  frame 
processing  is  basically  the  inverse  of  the  processing  initially  done  onboard. 
TV/audio  is  recovered  and  retransmitted  over  point-to-point  links  and  the 
1M/IC  packets  re-enter  the  ISO/OSI  environment  as  shown  with  the  indicated 
distribution  options. 
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Figure  4.3.2-2.  End-to-End  TM  Packet  Flow  (3  of  3) 


4 • 4 System  Control/Management  Definition  within  the  SSDS 

This  section  provides  1)  a summary  of  the  systems  management  and  control 
decisions  and  design  allocations;  2)  a summary  of  systems  management 
definitions;  3)  a pictorial  description  of  the  interrelationships  and  data 
flows  among  the  different  management  functions;  and  4)  a baseline  systems 
management  definition  and  allocation  among  elements  of  the  SSDS. 

4.4.1  Summary  of  System  Control/Management  Design  Decisions  and 

Functional  Allocations 

This  section  summarizes  definitions  of  systems,  facilities,  resource,  command, 
configuration,  and  administrative  managements,  their  interdependencies , and 
their  functional  allocations  to  the  SSPEs  as  part  of  the  strawman  SSDS 
definition . 


The  basic  design  approach  has  been  to  assign  a high  level  of  management 
function  autonomy  to  each  SSDS  facility.  With  the  exception  of  centralized  SS 
system  communications  coordination,  each  facility  has  responsibility  for 
managing  local  resources,  validating  and  executing  commands,  and  monitoring 
its  performance.  A Ground  Services  Center  (GSC)  facility  is  proposed  to 
coordinate  inter-element  communications,  coordinate  management  of  resources 
allocated  to  common  elements  (such  as  the  Data  Handling  Center),  and 
coordinate  customer  interactions  with  the  SSDS. 

Arguments  are  presented  for  space/ground  resource  management  autonomy 
(subsequent  to  the  man— tended  Space  Station  era).  Key  design  drivers  in 
allocating  system  management  functions  are  discussed.  Guidelines  for  the 
scope  of  management  and  monitoring  function  implementation  are  presented.  A 
summary  of  key  issues,  such  as  potential  national  security  involvement  and 
accommodation  of  international  customers,  concludes  this  section. 

4.4.2  Definition  of  Key  Management  Terms 

The  definitions  below  are  with  respect  to  the  strawman  system  definition 
proposed  for  the  Space  Station  Data  System  (SSDS)  Architecture  Study.  The  key 
types  of  management  defined  are  systems  management,  facilities  management, 
command  management,  configuration  management,  and  administrative  management. 

SYS1EMS  MANAGEMENT:  Systems  management  is  the  management  of  the  overall  SSDS 

and  its  associated  elements.  The  systems  management  function  is  the  highest 
in  the  hierarchy  of  SSDS  related  management  functions.  Systems  management 
encompasses  inter-facility  management;  overall  SSDS  communications  network 
scheduling;  system-wide  monitoring  and  performance  assessment;  system 
maintenance  procedures;  and  overall  system  control.  In  support  of  these 
functions  a predetermined  inference  and  arbitration  rule-set  will  need  to  be 
established  to  support  efficient  resource  utilization,  to  coordinate 
operational  procedures,  and  to  resolve  conflicts. 

The  ultimate  system  control  of  the  Space  Station  and  other  SSPE's  is  included 
in  this  top  level  systems  management  function.  System  control  refers  to  the 
coordinated  control  of  payloads,  core  resources,  facilities,  and  all  standard 
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user  resources  via  the  issuance  of  controls  and  the  prioritized  allocation  of 
resources  to  effect  desired  actions.  System  control  here  refers  to  the  higher 
level  control  and  coordination  functions  required  to  effect  orderly  actions 
within  the  SSDS,  not  simply  for  individual  resource  or  payload-specific 
actions  of  minor  importance  to  overall  system  functioning. 

FACILITIES  MANAGEMENT:  Facilities  management  is  the  management  of  subsystems 

within  a specific  facility.  A facility  represents  a distinct  physical  entity 
having  a well  defined  focus  or  goal,  such  as  a payload  operations  control 
center  (POCC),  a level  zero  processing  facility  (LZPF),  or  the  NASCOM  TDRSS 
network  (strictly  speaking,  an  institutional  facility  utilized  by  the  Space 
Station  program,  and  not  a part  of  the  SSDS).  The  facilities  management 
.function  includes  most  of  the  above  system  control,  management,  and  resource 
scheduling  functions,  but  at  a lower  level,  i.e.,  for  each  specific  facility. 
The  management  of  facility  reconf iguration,  i.e.,  the  reallocation  of  facility 
resources  for  changing  mission  requirements , is  included  in  the  facilities  and 
systems  management.  Facilities  management  will  also  include  resource 
management . 

RESOURCE  MANAGEMENT:  The  management,  control  and  scheduling  of  subsystem 

resources  such  as  computer  processing,  data  storage,  local  communications 
links  and  capabilities,  crew  utilization,  and  SSDS  core  functions  (such  as 
power,  thermal  management,  ECLSS).  The  overall  coordination  of  the 
communications  network,  which  may  require  interfacility  scheduling,  is  part  of 
the  higher  level  systems  management  function.  The  resource  management 
function  controls,  schedules,  monitors,  maintains,  and  reports  on  the  usage, 
performance,  and  reserve  capabilities  of  the  individual  resources  for  each 
facility  within  the  SSDS  network. 

COMMAND  MANAGEMENT:  The  handling,  checking,  validation,  and  authorization  for 

command  execution.  Command  management  can  be  localized  to  a particular 
payload  or  core  subsystem,  or  it  may  extend  to  a facility  or  the  overall 
SSDS.  Restricted  commands  will  require  more  checking  and  coordination  than 
unrestricted  commands,  which  can  be  passed  in  a transparent  manner  to  the 
payload.  Restricted/constrained  commands  can  be  executed  as  conditions  permit 
(safety,  interference , resource  availability),  where  executability  is 
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determined  by  the  onboard  SSDS,  scheduling/negotiation  functions  to  reserve 
time/resource  envelopes  for  future  utilization  Command  management  will 
normally  be  a subset  of  systems  and  facilities  resource  managements  and  is 
discussed  in-depth  in  Paragraph  4.5. 

CONFIGURATION  MANAGEMENT:  The  management  and  control  of  system  upgrades , 

updates,  and  associated  documentation.  Configuration  management  deals  with 
assuring  control  of  hardware  and  software  versions  and  updates,  update 
documentation  control,  and  updates  logistics.  Included  are  updates  to  command 
and  control  tables  and  data  access  authorization  tables. 

ADMINISTRATIVE  MANAGEMENT:  The  management  of  accounting  and  resource  usage 

data,  the  provision  of  standard  system  documentation,  the  facilitation  of  the 
customer  interface  for  SSDS  information,  etc.  Administrative  management  is 
required  within  systems  management  and  facilities  management,  but  at  different 
levels . 

4.4.3  Interrelationships/Dependencies  of  Different  Management  Categories 

Figure  4. 4. 3-1  shows  a hierarchy  of  management  functions  and  their 
relationships  among  themselves  and  among  the  different  SSPEs. 

Management— related  data  flows  between  the  SSPEs  and  associated  management 
functions  are  indicated. 

4.4.4  System  Control/Management  Design  Definition 

This  section  presents  a rationale  for  separate,  autonomous  facilities 
management  and  control  functions  within  the  space  elements  and  within  the 
ground  elements  of  the  SSDS  as  depicted  in  Figure  4. 4. 3—1.  The 
characterization  of  key  interfaces  among  SSDS  elements  in  the  area  of  systems 
management  and  control  is  also  delineated  in  this  figure. 

The  definition  of  key  space  and  ground  elements  and  the  allocation  of  key 
management  and  control  functions  among  these  elements  is  presented  next.  Many 
of  these  allocations  will  of  necessity  be  repetitive  in  that  many  different 
elements  will  require  the  capability  to  perform  subsets  of  these  functions 
autonomously  of  other  elements. 
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Figure  4.4.3-1.  Interrelationships  Among  SSDS  Management  Functions  and  SSPEs 


4.4.4. 1 Ground  and  Space  Autonomy  Philosophy 

In  the  baseline  SSDS  design,  facilities  management  will  be  distributed  among 
ground  facilities  and  space  facilities.  This  division  will  be  necessary  - 

1)  to  facilitate  Space  Station  autonomy  for  normal  operations,  and  to 
control  space  facilities  in  emergency,  real-time  critical  situations 
where  transmission  delay  times  to  ground  might  be  detrimental  and 
where  the  control  of  operations  by  trained  crew  might  be  invaluable; 
and 

2)  to  coordinate  and  manage  the  distributed  array  of  ground  facilities, 
the  management  of  which  will  be  burdensome  and  inefficient  if 
centralized  in  a space  node,  such  as  the  Space  Station  base. 
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The  space  segment  will  require  responsiveness  and  real-time  human  interaction 
capability  in  emergency  situations;  the  space  segment  is  also  best  equipped  to 
perform  dynamic  onboard  command  management  and  onboard  resource  allocations. 
The  ground  elements  will  best  manage  themselves  due  to  the  disparate  locations 
and  diversity  of  functions  among  these  elements  and  the  impractical ity  of 
controlling  any  portion  of  them  from  space. 

Since  the  ground  LZPFs  and  DHC  may  serve  multiple  missions  and  multiple 
customers  located  at  diverse  facilities,  an  additional  coordinators  management 
function  is  proposed,  which  will  coordinate  multiple  customer  requests  and 
manage  inter— facility  resources  shared  in  common  by  a broad  spectrum  of 
customers.  In  space,  multiple  customer  requests  to  the  Space  Station  will 
also  require  only  the  resources  of  this  single  facility  with  the  exception  of 
shared  or  common  communications  resources. 

With  regard  to  the  question  of  whether  space  or  ground  has  ultimate  control, 
for  situations  where  unresolvable  systems  management  conflicts  may  occur,  it 
is  proposed  that  the  ground  be  the  ultimate  location  of  decision-making 
authority  for  the  simple  reason  that  top  NASA  administrators,  who  have 
ultimate  Space  Station  program  responsibility,  are  almost  surely  to  be  on 
ground  in  such  situations.  This  is  not  to  imply  that  the  Space  Station  crow 
will  not  have  definitive  decision-making  authority  for  most  ongoing  and 
emergency  situations.  Backup  control  capability  on  the  ground  is  also 
valuable,  however,  in  cases  of  extensive  crew  incapacitation,  severe  onboard 
facilities  damage,  etc. 

An  important  area  for  coordination  and  priority  specification  will  be  the 
scheduling  of  communications  resources.  Emergency  situations  will  require  the 
highest  communications  scheduling  priority. 

It  is  proposed  that  a predetermined  set  of  arbitration  rules  and  procedures  be 
established  to  coordinate  space  and  ground  communications  control  and  resource 
allocation  for  predictable  situations  likely  to  occur  during  ongoing  Space 
Station  Program  operations  and  missions.  A sample  set  of  such  rules  was 
presented  at  a high  level  in  Section  3.6. 


4-58 


Another  important  area  for  management  coordination  is  the  control  of  updates 
and  access  to  data  bases  required  by  both  ground  and  space  nodes.  Each  data 
base  will  be  under  control  of  each  facility  management  function,  with  shared 

data  bases  controlled  by  the  system  management  and  communications  coordination 
functions . 

4. 4. 4. 2 Definition  of  SSDS  Space  and  Ground  Elements  and  Associated 
Management  Functions. 


The  space  SSDS  elements  which  will  need  to  be  managed  and  controlled  include 
the  Space  Station  and  the  Co-Orbiting  and  Polar  Orbiting  Platforms,  as 
discussed  in  Section  3.3. 

The  ground  SSDS  elements  needing  management  and  control  will  include  the  Space 
Station  and  platform  operations  control  centers  (SSOCC,  COPCC,  and  POPCC),  the 
LZPFs , the  Engineering  Data  Center(s)  (EDC) , the  Data  Handling  Center  (DHC) , 
the  Payload  Operations  Control  Centers  (POCCs),  and  the  Develop,  Simulation, 
Integrate  and  Train  (DSIT)  facility,  as  described  in  Section  3.3. 

In  addition,  there  is  proposed  on  the  ground  a Ground  Services  Center  (GSC) 
which  would  be  responsible  for  the  management  of  common  ground  facilities  (DHC 
and  LZPFs);  the  SSDS  network  communications  coordination  and  scheduling;  and 
the  interfacing  of  customer  access  to  other  SSDS  elements  and  services. 

The  common  facilities  Management  function  of  the  GSC  will  encompass  the 
resource  management  condition  of  the  common  facilities,  the  intei — facility 
coordination,  and  prioritized  resource  allocation  and  conflict  resolution 
among  and  within  these  facilities. 

The  Communications  Coordination  function  of  the  GSC  will  coordinate  Space 
Station  Program  requests  for  network  communications  services  with  other 
institutional  facilities  such  as  the  NCC,  the  DSIM,  the  GPS,  or  the  NASCOM 
TDRSS  network.  The  GSC  will  serve  as  the  network  scheduling  interface  between 
these  existing  institutional  facilities  and  the  SSDS  and  Space  Station  Program 
elements . 
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The  functional  architecture  proposed  here,  with  significant  autonomous 
management  within  individual  facilities,  should  facilitate  function  migration 
from  ground  to  space  with  minimal  impacts  on  other  facilities. 

4.4.5  Major  Assumptions/Design  Drivers 

The  management-related  SSDS  functions  and  interrelationships  developed  in  the 
Task  1 functions  data  base  and  data  flow  diagrams  served  as  the  basis  for 
management  function  partitioning  and  SSPE  allocations.  In  addition,  four 
design  drivers  had  a major  impact  on  the  allocation  of  SSDS  systems  management 
functions.  These  were  the  requirements  1)  for  protection  of  Space  Station 
system  assets;  2)  for  system  responsiveness  and  transparency  in  customer 
interactions;  3)  for  high-level  and  broad  based  automation  and  autonomy 
implementation;  and  4)  for  flexibility  of  ongoing  subsystem  upgrades 
throughout  the  life— cycle  of  the  Space  Station  Program.  These  are  discussed 
further  below. 

4 • 4 . 5 . 1 Protection  of  Space  Station  Resources/Assets 

A primary  Space  Station  Program  requirement  is  the  protection  of  onboard  and 
ground  assets  and  people.  Life  threatening  situations  can  occur  in  numerous 
ways  onboard  if  adequate  safety  precautions  or  subsystem  redundancy  are  not 
available  in  times  of  emergency  or  subsystem  failures.  With  respect  to  the 
SSDS,  a high  level  of  operational  reliability,  functional  adequacy,  and 
assured  and  secure  command  and  control  procedures  are  necessary. 

This  set  of  requirements  for  safety  and  security  imply  that  system  management 
functions  such  as  configuration  management  control,  efficient  and  dynamic 
resource  allocations  and/or  conflict  resolutions,  and  well  formulated 
inference  and  arbitration  policies  and  associated  technology  to  effect  them 
are  necessary.  The  need  for  efficient  management  as  well  as  high  fault 
tolerance  and  redundancy  of  functionality  escalate  the  assorted  systems 
management  functions  in  priority  within  the  SSDS. 
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4 . 4 . 5 . 2 System  Transparency/User  Responsiveness 


The  priority  of  transparent  data  handling  and  commanding  as  well  as  near 
real-time  responsiveness  for  customers  translates  into  a very  efficiently 
managed  and  coordinated  system.  This  suggests  that  many  functions  which  may 
otherwise  have  been  centralized  at  remote  locations  should  be  distributed  to 
effect  quick,  straightforward  responses.  Command  checking  and  data  handling 
cannot  be  extensive  for  normal  non-threatening  situations  or  user- 
responsiveness  may  be  impacted.  A basic  philosophy  has  been  to  reduce  the 
hierarchy  and  number  of  management  functions  so  as  to  reduce  necessary 
functional  and  inter— facility  interfaces  in  command  management  and  resource 
scheduling.  A clearly  defined  set  of  policies  and  associated  management 
functions  are  thereby  required  for  these  reasons.  This  implies  rapid 
transparent  command  routing  and  distribution.  In  conjunction  with  the  safety 
requirements  noted  above,  this  implies  a highly  secure  and  well  engineered 
Space  Station  base  DMS  operating  system,  where  ultimate  control  and  allocation 
of  onboard  resources  will  be  managed. 

Network  monitoring  and  performance  assessment  will  be  needed  to  assure 
adequate  and  reliable  system  performance,  but  a highly  centralized  control  of 
all  of  this  monitoring  data  may  impact  system  performance.  This  likewise 
suggests  a highly  distributed  monitoring  and  performance  assessment  function, 
at  least  at  the  facility  level,  with  coordination  of  overall  network  data 
required  only  for  small  subsets  of  higher  level  performance  data. 

Similarly,  command  management  is  best  distributed  on  the  ground,  with  the 
capability  for  command  authentication  and  final  authorization  occurring  within 
the  onboard  SSDS.  In  this  manner  non-restricted  commands  generated  by 
geographically  separated  customers  can  be  efficiently  routed  within  data 
streams  without  the  necessity  of  centralized  ground  validation  and 
verification.  Ground  validation  of  ground  related  commands  will  be  required, 
but,  as  much  as  possible,  in  a distributed  fashion,  and  at  the  facility  level 
or  lower. 
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4 . 4 . 5 . 3 Operational  Autonomy/Automation  Key  Requirements 


A major  Space  Station  Program  goal  is  to  maximize  autonomy  of  operations  and 
to  maximize  the  implementation  of  automated  processes.  For  many  routine 
operations,  automation  is  both  cost  effective  and  more  reliable.  Automation 
is  expected  to  be  implemented  stepwise  during  the  Space  Station  Program  as 
automation  technology  processes  mature. 

An  eventual  highly  automated  system  will  require  thorough  configuration 
management  during  its  development  and  integration,  and  ongoing  monitoring  and 
assessment  of  its  functioning.  A distribution  of  the  monitoring  function  is 
again  valuable  in  detecting  failures  in  automated  subsystems  and  in  providing 
quick  functional  backups. 

4. 4. 5. 4 Upgradeability  of  SSDS  Elements 

As  technology  develops,  both  ground  and  space  SSDS  components  will  be 
upgraded,  and  an  ever— increasing  number  of  functions  will  migrate  from  a 
ground-based  implementation  to  an  autonomous  space  functionality.  Again,  this 
will  require  a broad  and  thorough  system-wide  configuration  management 
function  to  assure  adequacy  of  updates,  logistical  feasibility,  and  adequacy 
of  functional  redundancy  in  case  of  failures.  Assurance  of  inter— subsystem 
data  exchange  and  communication  compatibility  will  also  be  necessary. 

4,4,6  Architectural  Design  Decisions/Management-Related  Functiona 1 
Allocations 


Table  4. 4. 6-1  are  summarizes  the  major  architectural  functional  allocation 
decisions  with  respect  to  systems  management  and  control  within  the  SSDS.  As 
can  be  seen  in  the  lable,  each  facility  will  have  autonomous  responsibility 
for  local  performance  monitoring,  configuration  management,  and  administrative 
management.  Appropriate  subsets  of  data  from  these  functions  will  be  sent 
periodically  to  the  higher  level  ground  facilities  management  and/or  systems 
management  functions, 
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Table  4.4 .6-1.  Systems  Management  SSPE  Allocations 


Management  Function 

Space  SSPE 

Ground  SSPE  | 

COP 

H2 

GSC 

SSOCC 

COPCC 

POPCCs 

EDC 

POCCs 

DHCs 

LZPFs 

Systems  Management 

X 

II 

— 

firm 

1.  Communications  Coord 

X 

■ 

^■1 

■ 

m u 

2-  System  Performance  Monitoring 

X 

1 

MM 

■ 

■ 

1 

Facility  Mgt 

X 

X 

X 

X 

X 

X 

— 

X 

X 

X 

X 

X 

a.  Resource  Management 

mm 

n 

mm 

X 

X 

X 

X 

wm 

X 

X 

X 

b.  PL/Ops  Scheduling 

mm 

X 

X 

X 

X 

1)  Lonq  Term 

X 

X 

X 

X 

2)  Short  Term  (2  wks  -►  1-2  hrs) 

X 

X 

X 

X 

3)  Near  Term 

X 

■ 

X 

X 

X 

X 

c.  RT  Command  Management 

mm 

X 

mm 

■ 

X 

X 

X 

X 

d.  Performance  Monitoring 

X 

Kfl 

X 

X 

X 

X 

X 

X 

X 

e.  Configuration  Management 

mm 

X 

mm 

X 

X 

X 

X 

X 

X 

X 

X 

f.  Administrative  Management 

X 

X 

MM 

X 

X 

X 

X 

X 

X 

X 

X 

Each  facility  will  have  responsibility  for  managing  its  own  SSDS  resources. 

In  addition,  a proposed  ground  facilities  management  function  will  coordinate 
resources  and  resolve  conflicts  among  ground  elements  serving  multiple  SSPEs, 
i.e.,  the  DHC  and  LZPFs.  The  Space  Station  and  platform  control  centers  will 
be  dedicated  to  a single  SSPE  or  mission  set  and,  except  for  communications 
coordination,  will  not  require  significant  interfacility  coordination. 

The  systems  management  function,  located  in  the  proposed  Ground  Services 
Center,  will  coordinate  the  scheduling  of  TDRSS  network  communications  with 
the  NCC  and  coordinate  and  negotiate  space/ground  communication  requests. 
Although  space  and  ground  elements  will  primarily  downlink  and  uplink  data, 
respectively,  some  traffic  the  other  way  will  occur  in  each  case.  Onboard 
payload  specialists  may  request  data  from  the  ground  and  ground  customers  may 
send  operational  payload  information  to  the  station.  The  systems  management 
function  at  the  GSC  will  also  perform  system-wide  network  assessment  and 
configuration  management. 

4 . 4 . 6 . 1 Management/Control  Hierarchical  Design  - Ultimate  Control  Locations 

The  proposed  SSDS  design  does  not  encompass  much  hierarchy  above  the  facility 
level.  Each  facility  will  operate  autonomously  except  for  the  communications 
resource  scheduling,  common  ground  facilities  coordination,  and  high  level 
systems  monitoring  and  configuration  management. 
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The  Space  Station  will  therefore  have  ultimate  control  over  its  normal 
operations.  In  the  event  of  emergencies  or  Space  Station  subsystem 
malfunctioning,  the  ultimate  control  can  revert  to  the  ground  with  the  Space 
Station  Operations  Control  Center  assuming  a backup  role  in  this  area. 

4 . 4 . 6 . 2 Extent  of  Centralization/Distribution  of  Key  Management/Coitrol 
Functions 


An  important  design  philosophy  is  the  decentralization  of  function 
implementation  as  much  as  feasible.  This  distributed  philosophy  will 
facilitate  the  user-friendliness  and  transparency  desired  of  the  SSDS.  This 
distribution  will  be  feasible  due  to  the  rapid  advances  in  networking 
technology  and  associated  software  developments  (AI,  expert  systems,  etc.). 

The  resultant  autonomy  of  operations  will  require  extensive  validation  and 
verification  of  function  implementation  as  well  as  rigorous  configuration 
management  control  for  updates. 

4 . 4 . 6 . 3 Scope  of  Management/Control  Allocation  per  Ground/Space  Element 

Each  SSPE  will  control  itself  to  the  extent  necessary.  For  example,  at  a POCC 
a customer  may  request  Space  Station  resources  requiring  coordination  via  a 
mode  change.  If  scarce  onboard  resources  are  required,  this  would  need  to  be 
determined  either  at  the  SSOCC  or  onboard,  if  real  time  in  nature.  A highly 
centralized  or  hierarchical  command  management  scheme  is  not  warranted  if  each 
facility  has  the  ultimate  control  of  executing  commands  and  allocating 
resources.  The  Space  Station  will  be  the  controller  of  its  resources  and  will 
need  to  protect  itself  from  erroneous  or  harmful  commands,  either  by  physical 
means  or  logical  DMS  controls. 

In  general  each  facility  may  also  distribute  resource  management 
responsibilities  to  individual  autonomous  facility  subsystems  and  only  serve 
as  an  overall  coordinator  and  monitor  of  facility  operations. 

t 
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4 . 4 . 6 . 4 Scope  of  Monitoring/Accounting/Tracking  Performed 


The  basic  philosophies  regarding  of  performance  monitoring,  data  accounting, 
and  process  tracking  to  be  performed  within  the  SSDS  are: 

1.  These  functions  should  not  significantly  affect  system 
responsiveness,  impact  resource  availability,  or  impact  system 
development  or  operational  costs. 

As  a guideline  impacts  should  be  less  than  10%  of  that  resulting  from 
functions  implemented  for  basic  Space  Station  operations,  unless 
these  monitoring  and  accounting  functions  are  deemed  essential  for 
Space  Station  system  effectiveness. 

2.  Within  these  guidelines,  monitoring  and  accounting  should  be 
implemented  only  to  the  extent  justifiable  on  cost  and  utilization 
basis.  If  clear  and  important  uses  of  the  data  gathered  are  not 
evident,  the  data  should  not  be  taken  or  stored. 

3.  The  SSDS  should  be  designed  as  much  as  possible,  however,  to 
straightforwardly  incorporate  new  capabilities  in  these  areas  as 
needs  arise  with  time  and  evolving  mission  requirements . 

4 . 4 . 6 . 5 Coordination  of  Space/Ground  Management  Via  a Pre-established  Set  of 
Inference  Rules  for  Conflict  Resolution 

In  the  man-tended  Space  Station  era,  few  management  related  functions  or 
decision-making  will  be  implemented  onboard.  AI  techniques  will  still  not  be 
mature  and  the  absence  of  crew  will  affects  the  amount  of  ground  implemented 
management  of  space  resources.  The  eventual  goal,  however,  will  be  a nearly 
autonomous  manned  station,  with  most  management  and  decisions  performed 
onboard,  either  by  expert  systems  or,  as  needed,  by  crew  intervention. 

Conflicts  over  resource  utilization  and  activity  priority,  however,  will 
inevitably  arise  between  the  crew  and  onboard  systems  and  the  ground  based 
control  center  operators  and  customers.  Inasmuch  as  possible,  the  use  of  a 
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prenegotiated,  pre-established  set  of  decisions  to  guide  the  SSP  in  these 
conflict  areas  is  desirable.  The  development  of  these  inference  rules  will 
require  planning  and  contingency  analysis,  as  well  as  pre-mission 
negotiations,  on  the  part  of  customers  and  NASA  prior  to  mission  actualization. 

For  unforeseen  conflicts,  it  is  suggested  that  the  ground  program  managers 
have  final  decision  authority  with  the  exception  of  time  critical  or 
life-threatening  onboard  occurrences  for  which  the  crew  will  need  to  act  with 
real-time  responsiveness.  The  minimization  of  onboard  conflicts  suggests  the 
development  of  a thorough  DSIT  facility. 

4 • 4 . 7 Key  Issues  and  Recommendations  for  Further  Investigation 

4 • 4 • 7 • 1 Variation  of  Functional  Allocations  for  Customer  Classes/Data  Type s 

No  analysis  has  been  performed  to  determine  if  different  types  of  customers 
or  data  types  will  require  special  management  or  will  be  particularly  impacted 
by  the  proposed  management  design.  l\lo  impacts  are  obvious.  Requirements  of 
foreign  customers  have  also  not  been  evaluated  in  this  regard. 

4 . 4 . 7 . 2 Impact  of  Possible  Future  National  Security  Requirements 

If  national  security  requirements  become  an  eventual  part  of  the  SSP,  a 
separate  highly  secure  command  and  control  system  may  be  necessary.  Depending 
on  specific  hardware  and  software  architectures  selected,  compatibility 
problems  may  arise  with  respect  to  interfacing  to  approved  national  security 
processing  systems  or  encryption  devices. 

Re— evaluation  of  resource  allocation  priorities  and  revised  management 
strategies  would  be  likely.  If  the  utilization  of  SSP  assets  for  national 
security  purposes  appears  likely,  the  programmatic  issues  need  to  be  addressed 
as  soon  as  possible. 

4 . 4 . 7 . 3 Potential  Impacts  of  International  Requirements 

A key  issue  is  who  has  ultimate  authority  over  the  commanding  of  foreign 
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modules  or  payloads  attached  to  the  U.S.  Space  Station.  How  can  the  U.S.  be 
assured  that  foreign  operations  may  not  inadvertently  damage  or  impact  U.S. 
space  assets?  How  will  common  communications  resources  be  coordinated  and 
allocated? 

Another  policy  issue  relates  to  the  liabilities  on  NASA  if  it  impacts  foreign 
users  or  causes  a loss  of  data  or  privacy.  This  is  an  extension  of 
liabilities  to  U.S.  based  customers,  but  program  management  coordination  with 
foreign  countries  and  foreign  customers  will  be  difficult.  Some  experience 
has  been  gained  with  Spacelab  but  not  without  policy  and  programmat ic 
difficulties . 

Another  issue  is  whether  NASA  will  be  responsible  to  foreign  customers  for  the 
range  of  customer  services  currently  specified  for  the  SSDS.  Negotiations 
with  regards  to  data  processing  and  data  delivery  responsiveness,  data 
handling  transparency  and  provision  of  DSIT  services,  among  others,  need  to  be 
initiated  as  soon  as  possible  to  assess  possible  impacts  on  SSDS  and  SSIS 
designs . 

4.5  COMMAND  MANAGEMENT 
4.5.1  Introduction 
Definition 


A definition  of  an  SSDS  command  is  that  it  is  an  electronic  entity  that 
conveys  information  from  a user  to  his  payload  or  core  subsystem,  to  initiate 
the  execution  of  a computer  directed  sequence  (program)  that  results  in  some 
desired  action  or  response.  For  the  present  purposes,  commands  can  be  thought 
of  as  being  initiated  by  users  directly,  or  indirectly,  vocally  (voice 
recognition),  manually  (touch  panel),  automatically  (via  future  scheduled 
activity),  internal  to  an  SSPE  or  external  at  a POCC,  CC,  etc.  via  telecommand 
initiation,  real-  and  non-realtime  initiated,  and  so  forth. 

Commands  may  be  batch-assembled  onboard  or  on-ground  for  future  automatic 
execution  and  they  may  be  transported  indirectly  via  optical  or  magnetic 
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storage  media  or  directly  (electronically)  via  the  SSDS.  Commands  may  be 
issued  in  realtime,  on  a one-at  a-time  basis,  from  within  the  SSPE  or  from  a 
ground-based  center.  Numerous  options  will  be  supported  by  the  SSDS  as  will 
be  described  later. 

Commands  can  also  be  considered  in  a hierarchical  sense  and  at  a macro-  and 
micro-level  and  can  exist  in  numerous  encoded  formats  at  an  instant  of  time, 
as  illustrated  by  the  following  examples: 

COMMAND  COMMAND  ENCODING 

"OPEN  VALVE  13"  13  ASCII  characters  in  a telecommand  packet. 

"OPEN  VALVE  13"  256  Bytes  of  MIL-STD-1750A  Code. 

"ACTIVATE  ATTITUDE  8 Bytes  in  the  information  field  of  a LAN 

CONTROL  SUBSYSTEM"  (Layer  2)  packet. 

COMMAND  COMMAND  REALIZATION 

"ACTIVATE  ATTITUDE  64  KBytes  of  embedded  and  distributed 

CONTROL  SUBSYSTEM"  subsystem  control  instructions. 

"ACTIVATE  SAX  0123"  A sequence  of  20  subcommands  that  direct  the 

attachment  of  physical  and  communication 
resources  that  support  this  experiment. 

Micro-level  commands  are  the  lowest  level  of  command — for  an  effector  command, 
this  would  be  the  voltage  signal  delivered  at  an  analog  or  digital  output 
port.  Macro-level  commands  are  then  recursive  and  nested  sequences  of 
sub-macro  and  micro-commands.  Example  of  these  commands  are  shown  below  where 
the  brackets, [],  indicate  parameters  or  arguments  associated  with  the  command. 

MACRO  COMMANDS 


- Configure  Subsystem  J [] 

- Execute  Momentum  Dump  [] 
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- Position  Antenna  K [] 

- Execute  Auto-Calibrate  Procedures  SAX  5678  [] 

- Deploy  UVW  [] 

- Retract  XYZ  [] 

- Activate  Payload  Com  1234  [] 


MICRO  COMMANDS 


- Open/Close  Valve  [M] 

- Position  Effector  [N,....] 

As  an  example,  a user  might  send  the  command  OPEN  VALVE  13  as  an  english 
character  sequence  (e.g.,  EBCDIC  encoded)  which  could  be  interpreted  in  an  SDP 
by  a computer  subprogram,  or  he  may  send  the  entire  computer  subprogram  for 
execution.  Either  approach  results  in  the  same  effector  (VALVE  13)  action. 

Using  this  same  example,  the  implementation  of  the  command  OPEN  VALVE  13  is 
shown  in  Figure  4.5. 1-1,  where:  1)  the  command  is  initiated  externally  and 

manually,  at  a workstation  (trace  with  solid  line),  and  2)  where  the  command 
is  initiated  automatically  and  internally  (trace  with  dashed  line)  in  an  SDP 
program.  In  both  cases  a command  interpreter  (subprogram)  is  called,  with 
argument  [13],  that  initiates  the  I/O  subprogram  that  activates  effector 
(valve)  number  13. 

Two  final  points  here  are  that:  1)  Command  management  involves  the 

consideration  of  criticality,  where  commands  may  be  restricted  or  constrained 
based  on  the  current  operations  being  conducted  in  an  SSPE,  i.e.,  criticality 
varies  with  time  as  a function  of  SSPE  state  and  possibly  other  parameters, 
and  2)  Command  management  also  involves  the  consideration  of  the  availability 
of  resources  to  implement  a specific  command  at  any  instant  of  time. 

FUNDAMENTAL  ISSUES 

Some  fundamental  issues  (and  options  for  implementation)  in  command  management 
are  summarized  Table  4.5. 1-1  in  an  end-to-end  event  sequence  in  the  processing 
cycle  of  a command. 
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1 From  Workstation  (Interactively) 

2QFrom  Subsystem  Control  Algorithm  (Automatically) 


Effector 

(Valve) 

13 


Figure  4.5.1 -1.  Micro-Command  Implementation  with  Two  Instances  of  Initiation 


Table  4.5.1— 1.  Issues  in  Command  Management 

• Authorization  to  initiate/transmit  commands 

• Command  Receipt  (Data  Transport)  Validation 

Forward  error  checking 

Re-transmit  at  OSI  transport  and  CCSDS  transfer 
frame  layers 

Re-transmit  at  application  layer 

• Checks  for  executability 

SSIS  or  SSDS  resources  may  not  be  available  to  implement  the 
command  (resources  are  finite). 
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— The  command  will  result  in  a mode  of  operation  that  interferes 

with  another  payload,  i.  e.,  the  quality  of  data  captured  by  one 
or  more  of  the  payloads  is  affected.  This  situation  is  referred 
to  as  constrained  operations 

— The  command  will  result  in  a mode  of  operation  that  endangers 

the  crew,  an  SSPE's  or  its  payloads — physical  damage  and  loss  of 
life  are  possible.  This  situation  is  referred  to  as  restricted 
operations . 

• Verification  of  Command  Execution 

Appl ication-to-application  verification 

Indirect  verification  (data  F/B  observations:  Video,  T/M, ....) 

• Command  Traceability  (Command  Logging) 

— At  sending  end 

- At  receiving  end 

- At  both  ends  (end-to-end  verification/logging) 

Command  Authorization 


Users  are  required  to  be  authenticated  prior  to  transmitting  any  command. 

This  is  accomplished  by  LOGON  and  possibly  other  procedures  (e.g.,  voiceprint, 
fingerprint,  badge,  etc.).  Specific  users  identified  at  LOGON  time  will  only 
be  allowed  to  be  attached  (connected)  to  specific  pre-assigned  SSOS  entities 
(workstations,  certain  sectors  of  mass  store,  a specific  payload  or  subsystem, 
etc.);  browsing  throughout  the  SSDS  will  not  be  allowed  and  attempts  to 
violate  privileges  are  reported  to  the  network  control  center  via  the 
distributed  operating  system.  (Privacy  and  security  are  always  significant 
parts  of  any  private  or  public  data  network.) 

Onboard  Command  Management 

SSDS  Function  3.0  (See  lask  1 report)  includes  all  of  the  user  scheduling 
activity  and  subfunction  3.3  (which  is  onboard  allocated)  executes  commands 
contained  in  an  Operating  Events  List  (OEL) , an  example  of  which  is  shown  in 
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Figure  4.5. 1-2.  This  list  is  a table  of  time-ordered  commands  stored  for 
future  sequencing , and  is  updated  and  adjusted  in  near-realtime  as  on-demand 
requests  for  payload  activations  and  sequencing  are  received.  This  listing 
results  from  user  commands  and  SSDS/SSIS  coordination  and  negotiation  for 
on-demand  and  future-scheduled  payload  and  core  systems  activity. 


■ Operating  Events  List  (OEL)  Is  Time-Ordered  and  Executed  in  Sequence  by  Function  3.4 

■ At  Any  Point  in  Time,  Resources,  Constraints,  and  Restrictions  Are  Defined  that  Can 
Support  On  Demand  Event  initiation 

■ OEL  Is  Onboard  With  Identical  Copies  at  CC  and  GSC 


Current  Time 
11:53:08 

— 

Next 
Command 
Pointer — ■ 


Operating  Events  List  (Function  3.3) 


Event 

No. 

Time 

Activity 

Duration 

Resources 

E, 

11:40:00 

Activate 
SAX  XXXX 

0:58:00 

j 

E,., 

11:50:00 

Activate 
SAX  YYYY 

1:00:00 

<0,p Q)  / 

11:53:08 

Excess  Resources  = (A,B,...,C) 

E,., 

12:15:00 

Activate 
COMM  XXXX 

4:05:00 

(R,S,...,T)  j 

Excess  Resources  = (D,E F)  \— 

E,.3 

12:28:00 

Activate 
COMM  XXXX 

8:00:00 

<U,V W)  \ 

Excess  Resources  = 

nil 

E,.4 

12:38:00 

Deactivate 
SAX  XXX 

12:42:00 

Reboost  / 

Constraints  Restrictions 


(Last  Two 
Commands  Executed 

-Resources  Available 
for  On-Demand  Service 
for  Duration  of  25  Minutes 

-Resources  Available 
for  On-Demand  Service 
for  Next  13  Minutes 

-No  Resources  Available 
for  On-Demand  Service 


Figure  4.5. 1-2.  Operating  Events  List 


Function  3.3  is  implemented  in  a computer  program  that  receives  the  OEL  from 
Function  3.2  and  steps  down  this  time-ordered  listing  based  solely  on  time. 
Function  3.2  assembled  the  OEL  taking  into  account  requirements  for  resources, 
restrictions  and  constraints,  however,  these  components  of  the  OEL  are 
re-validated  in  terms  of  the  current  real  operating  mode  prior  to  executing 
each  command.  The  principal  points  to  be  noted  here  are  that:  1)  Function 

3.3  steps  down  the  t ime-ordered  Operating  Events  List  issuing  the  required 
commands  that  activate  and  deactivate  payloads,  subsystems,  ...,  and  2) 
commands  for  on-demand  payload  activation  and  sequencing  are  coordinated  by 
Function  3.2  and  when  resources,  restricted  and  constrained  demands  can  be 
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satisfied  (or  when  priority  allows  deactivating  an  active  payload  to  satisfy 
the  demands)  then  the  OEL  is  updated  immediately  to  include  the  on-demand 
request  (which  was  received  in  the  form  of  a command).  Various  scenarios  are 
possible  here;  one  that  allows  for  immediate  payload  activation,  activation 
within  a short  time  (e.g.,  seconds  or  minutes,  whenever  the  resources, 
constraints  or  restrictions  can  be  satisfied)  or  the  user  may  be  notified  that 
based  on  his  priority,  and  his  demand  for  some  specific  resource  (or 
constrained  or  restricted  operation)  he  cannot  be  immediately  attached  and  the 
next  window  of  operation  for  his  payload  is  at  time  XXX  XXX,  and  for  a 
duration  of  XXX  units  of  time. 

Scheduling  Activity 

It  is  the  intent  here  that  the  SSDS  be  as  friendly  to  users  as  is  possible  and 
that  he  have  full  access  to  his  payload  with  the  least  constraints  and 
limitations.  The  scenario  envisioned  is  that  after  he  executes  LOGON 
procedures  (at  a minimum:  password,  account  no.,  and  application  process  ID) 

and  is  authenticated  by  the  SSDS,  he  can  freely  communicate  with  his  payload, 
e.g.,  turn  it  ON,  turn  it  OFF,  execute  diagnostics,  perform  calibration,  quick 
look,  ...  . Some  limitations  in  this  procedure,  however,  are  obviously 
mandatory  based  on  common  sense  safety  and  engineering  principles.  These 
include  the  following: 

1.  SSIS  or  SSDS  space/ground  resources  may  not  be  available  to  implement 
the  command . 

2.  The  command  will  result  in  a mode  of  operation  that  interferes  with 
another  payload  so  that  the  quality  of  the  data  captured  by  one  or 
more  of  the  payloads  is  affected.  (This  situation  is  referred  to  as 
constrained  operations.) 

3.  The  command  will  result  in  an  operation  that  endangers  the  crew,  an 
SSPE,  or  another  payload  — physical  damage  is  possible.  (This 
situation  is  referred  to  as  restricted  operations.) 
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The  following  key  points  are  reiterated: 

1.  SSI'S  and  SSDS  resources  in  space  and  ground  are  finite  and  must  be 
carefully  managed. 

2.  Constrained  operations  affects  the  quality  of  data  captured,  the 
effects  of  which  may  not  be  immediately  observable. 

3.  Restricted  operations  involves  hazardous  situations  that  endanger 
crew  life  and/or  affect  equipment  damage. 

Obviously,  the  user  may  have  the  priority  to  adjust  the  current  SSPE's 
operations  so  that  his  command  can  be  immediately  executed  or,  if  not,  he  must 
enter  an  interactive  negotiating  phase  with  Function  3.2  (scheduling  activity) 
to  arrive  at  an  agreed-to  future  timeline  of  operation.  This  scenario  is 
depicted  in  Figures  4.5. 1-3  and  -4  which  shows  users  coordinating  with  control 
centers  to  develop  this  agreed-to-schedule . 


Figure  4.5.1 -3.  Schedule  Development 
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Figure  4.5. 1*4.  Schedule  Development 
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Realtime  Payload  Command  Management 


At  this  point  a preview  and  summary  of  the  recommended  payload  command 
management  system  is  given  with  details  to  follow  later.  The  management 
concept  proposed  is  automated  and  implemented  onboard  and  in  realtime  — user 
are  given  maximum  flexibility  to  interact  with  their  payloads  and  subsystems, 
but  will  be  disconnected  (reactive  control)  if  their  operations  exceed 
parameters  associated  with  the  original  connect/attach  commands. 

Additionally,  the  system  also  includes  a priority  structure  so  that  lower 
priority  payloads  can  be  automatically  disconnected  to  provide  resources  for 
higher  priority  operations.  This  leads  to  a totally  automated  management 
system  that  can  be  driven  by  one  of  the  following:  schedule,  on-demand 

requests,  and  event -oriented  observations  experienced  by  a payload.  This  is 
especially  important  for  the  unmanned  SSPEs. 
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Numerous  strategies  and  options  for  command  management  have  been  proposed  and 
many  appear  to  be  reasonable  until  one  attempts  to  implement  them  in 
realistically  sized  hardware  and  software.  The  problem  one  encounters  is  that 
the  systems  become  extremely  complex  with  large  overheads  and  time  delays  and 
even  then  "sneak  circuits"  may  still  exist  that  could  allow  a restricted 
command  to  be  executed  in  certain  extremely  remote  and  in  unusual 
circumstances.  It  is  expected  that  safety  will  be  a principal  consideration 
in  the  management  of  commands  and  that  command  management  systems  cannot  be 
implemented  in  a way  that  cannot  be  analyzed  to  be  proven  to  be  free  of  hidden 
logical  and  physical  paths  that  could  lead  to  the  execution  of  a restricted 
command  and  a subsequent  catastrophic  event.  For  this  reason  the  system 
described  later  will  use  an  independent  "electronic  key"  that  controls 
resources  (predictive  control)  required  for  restricted  operations. 

Core  command  management  is  considered  separately,  later. 

A. 5. 2 Resource-limited,  Constrained,  and  Restricted  Operations 

This  paragraph  will  introduce  a formalism  that  attempts  to  capture  the  problem 
of  payload  command  management  in  terms  of  a model  that  allows  or  inhibits 
commands  to  a payload  based  on  the  three  considerations  previously  discussed: 
resource  limitations,  mutual  compatibility  and  cross-interference  associated 
with  multiple  payload  operations  (Constrained  Operations),  and  hazardous 
operations  that  affect  crew  safety  and  physical  damage  to  pay loads/core/SSPE 
structures  and  equipment  (Restricted  Operations).  Associated  with  these  three 
considerations,  we  shall  define  a triplet  T of  vector  components  RSCRCS, 

CONSTR , and  RESTRICT,  defined  as  follows: 

T = [(RSCRCS), (CONSTR), (RESTRICT)] 
where 

Resources  = RSCRCS  = (a^,  a^,  ...  a.). 

Constraints  = CONSTR  = (b^  b2,  ...  bk), 

Restrictions  = RESTRICT  = (c  , c , ...  c ). 
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The  components  of  each  of  the  three  vectors  are  an  ordered  set  of 
not-necessarily  numerical  components,  as  will  be  described  in  detail  later. 

For  now  a brief  description  of  each  vector  is  given  below: 

RSCRCS  - Has  components  which  are  the  SSIS/SSDS  resources  available  at 
some  instant  of  time  or  that  are  required  to  support  a certain  payloads 
operation  immediately  or  at  some  future  time  and  in  some  specific  mode  of 
operation . 

CONSTR  - Has  components  that  specify  the  compatibility  between  payloads; 
compatibility  here  relates  to  interference  between  payloads  that  may 
affect  data  quality  captured  by  one  or  more  payloads. 

RESTRICT  - Has  components  that  specify  non-compatibility  of  a payload  and 
other  SS  functions  that  affect  hazardous  operation  associated  with  safety 
and  physical  damage  considerations. 

The  problem  in  command  management  can  now  be  stated  as  follows:  At  no  time 

shall  an  SSPE's  payload  be  operated  so  that  constraints  associated  with 
RSCRCS,  CONSTR,  and  RESTRICT  are  violated.  The  implementation  of  this  rule  is 
discussed  later. 

4.5.3  Modes  of  Operation 

The  normal  flow  for  a payloads  space  operation  is:  delivery  to  space,  SSPE 

integration,  production,  and  finally  disconnect  and  transport  back  to  earth. 
Within  the  integration  and  production  phases  one  can  usually  identify  several 
modes  of  operation  (e.g.,  test,  checkout,  diagnostics,  calibration,  production 
mode  1 (high  power),  production  mode  2 (low  power),  and  so  forth)  where  the 
RSCRCS,  CONSTR,  and  RESTRICT  vectors  may  have  different  values  for  each  mode. 
The  point  here  is  that  at  some  instant  of  time,  a payload  may  be  allowed  to 
operate  in  MODE  1 (e.g.,  checkout/diagnostics)  but  not  in  MODE  3 (e.g., 
production),  for  reasons  associated  with  violations  in  these  constraints. 

These  concepts  are  illustrated  in  Figures  4. 5. 3-1  and  -2. 
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Example  1 
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State  Diagram  for  Two-Stage 
T-FF  Machine 


Machine  Operates  in  Four  Modes 


Figure  4.5.3-1.  Finite  State  Automata  (Mode  Diagrams) 
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Command  Checking 


4.5.4  Definition  of  RSCRCS  (Resources) 

The  components  of  RSCRCS  are  an  ordered  set  of  SSIS/SSDS  resources  required  to 
support  the  operation  of  a payload(s)  or  the  excess  SSIS/SSDS  resources  that 
are  available  at  some  instant  of  time.  Figure  4.5.4— 1 illustrates  the  notion 
in  a table  where  the  rows  are  the  complete  set  of  payloads,  and  the  columns 
are  the  ordered  and  complete  set  of  resources.  The  entries  in  row  i 
constitute  components  of  the  vector  RSCRCS(i)  required  for  a specific  mode  of 
operation  for  the  i 1 th  payload.  It  follows  then  that  the  total  resources 
required  at  any  instant  of  time  to  support  all  active  payloads  is  the  vector 
quantity 


l\) 

Z RSCRCS(i)*A(i) 
i:=l 
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RSCRCS  — (3^  djvofSj) 
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Example:  Payload  2 (SAX  XXXX),  Mode  2 (Calibration) 


Figure  4.5.4-1.  Resource  Requirements 


where  A(i)  is  a binary-valued  discrete  that  takes  the  value  1 if  a payload  is 
active  or  0 if  a payload  is  powered  OFF.  It  is  a function  of  the  scheduler  to 
assure  that  no  planned  operations  exceed  the  capability  of  the  SSIS/SSDS 
resources,  and  it  is  the  responsibility  of  the  command  manager  to  disconnect 
payloads  exceeding  any  one  component  of  RSCRCS(i).  Many  of  the  components 
will  be  sensed  directly  (power,  TCS,  ...)  and  others  will  be  sensed  indirectly 
(e.g.,  crew  time).  In  the  case  of  crew  time  the  customer  may  be  given  an 
option  (and  the  cost,  say  at  $50K/Hr)  to  continue,  for  example,  diagnostics  on 
his  payload,  or  the  SS  commander  may  discontinue  the  operation  once  his 
allocation  for  this  resource  is  exceeded.  Excess  resources  are  computed  by 
subtracting  the  vector  SRES  from  the  vector  ARES,  the  available  resources  at 
that  instant  of  time. 

4.5.5  Constrained  Operations 

The  definition  of  constrained  operations  evolves  around  the  mutual 

compatabi lity  of  operation  between  PAYLOAD,  and  PAYLOAD,  and  between 

i J 

PAYLOAD,  and  certain  core  operations.  A constraint  parameter  C. . (see 
i li 
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Figure  4. 5. 5-1)  is  defined  to  be  the  constraints  that  the  i'th  payload  (in  row 
i)  places  on  the  operation  of  the  j'th  payload  (in  column  j).  For  example, 
the  i'th  payload  may: 


Figure  4.5.5-1 . Payload-to-Payload/Core  Constraint  Matrix 


1.  Place  no  constraints  on  payload  j. 

2.  Place  limited  constraints  on  payload  j (e.g.,  the  j'th  payload  can 
operate  in  the  standby  or  calibrate  modes  but  not  in  the  production 
mode  where  it  has  a spectral  emission  that  interferes  with  payload  i). 

3.  Place  total  constraints  that  inhibit  payload  j from  being  powered  ON 
in  any  mode. 

The  diagonal  matrix  elements  are  not  meaningful  and  are  not  defined  and  the 
matrix  is  not  symmetric. 
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The  matrix  will  be  initially  prepared  during  the  initial  feasibility 
discussions  with  the  customer  to  determine  cross-interference  impacts  between 
payloads  and  realizable  windows  of  operation.  The  matrix  obviously  changes 
with  payload  changeout  and  may  be  adjusted  during  space  operations  when 
unanticipated  coupling  between  payloads  is  observed  to  degrade  the  quality  of 
data  collected  by  a payload. 

4.56  Restricted  Operations 

Restricted  operations  include  the  hazardous  operations  resulting  from 
activation  of  certain  payload  operating  modes.  The  commands  to  activate  these 
modes  will  be  defined  to  be  restricted  and  will  be  inhibited  by  the  SSDS  when 
incompatible  with  other  operations.  These  other  operations  may  include: 

1.  Other  payload  operations  (e.g.,  possible  hazardous  operations 
resulting  from  production  of  incompatible  byproducts  including 
solids,  gasses,  . . . ) . 

2.  EVA  Operation 

- Total  SS  sphere  of  proximity  ops 

- Subset  of  total  proximity  sphere 

- With  safety  provisions  such  as  laser  protective  eyewear 

3.  IVA  Operation 

- Module  must  be  unmanned  when  payload  operating 

- Module  must  be  manned  to  verify  correct  operation  of 
payload 

4.  OMV , OTV , Orbiter  Operations  in  proximity  of  an  SSPE. 

This  concept  is  illustrated  in  Figure  4. 5. 6-1  with  an  example  definition  of 
the  vector  RESTRICT. 


4-82 


RESTRICT  = (c„  c*..,  cj 


4.5.7  Levels  of  Command  Inhibition 

The  problem  in  implementing  a command  management  system  is  to  inhibit  commands 
that  violate  constraints/requirements  associated  with  the  components  of  T 
(RSCRCS,  CONSTR,  and  RESTRICT).  Three  levels  of  control  can  be  identified: 

1.  Function  3.0  absolutely  controls  which  payloads  are  consuming 
resources  and  the  quantities  of  resources  being  used  (e.g.,  power, 
flow  rates,  crew  time,  ...).  The  utilization  of  resources  is  sensed 
directly  (e.g.,  current  sensors  for  each  payload)  and  also  indirectly 
(use  of  crew  people  vs  time).  Payloads  will  be  detached  from 
resources  when  OEL-specif ied  allocations  are  violated  (reactive 
control) . 

2.  Payloads  are  only  allowed  to  communicate  with  certain 

subsy stems/servers  as  determined  by  the  OEL.  Function  3.3  contains 
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the  negotiated  schedule  for  resources/entities  and  directs  session 
establishment  (connections)  with  only  these  authorized  entities. 
Payloads  will  typically  communicate  (connect  to)  workstations,  mass 
stores,  C&T , and  Function  3.0.  Any  attempt  to  communicate  with  other 
payloads/core  systems  directly  will  be  reported  (as  an  unauthorized 
access  attempt)  to  Layer  7 Network  Control/Security  via  Layer  4 
Reporting  Statistics. 

3.  This  level  is  the  problem  area;  where  a payload  has  direct 
access/control  over  effectors  that  can  violate 

constraints/restrictions  that  were  placed  on  it  when  it  was  powered 
ON,  e.g.,  a payload  may  be  attached  for  diagnostics  or  calibration 
only,  and  is  constrained/restricted  from  entering  a mode  where  its 
primary  instrument  (e.g.,  a laser  illuminator)  is  turned  ON. 

4.5.8  Command  Management  Options  and  Selected  Approach 

4.5.8. 1 Payload  operations 

Command  management  options  for  payloads  are  discussed  below: 

1.  Prior  to  enabling  a payload,  check  its  processor's  executable  code 
for  restricted/constrained  commands.  The  problems  with  this  option 
are : 

a.  Difficult  to  implement:  I/O  can  be  activated  by  numerous 

addressing  options  — direct/indirect/subroutine/random  number 
generator/ . . . , many  possible  instruction  sets,  and  so  forth. 

b.  CPU  generates  "garbage"  causing  inadvertent  I/O  operation, 
resulting  in  a uncontrolled  restricted  operation. 

2.  For  command  checking  after  activation:  route  all  commands  thru 

Function  3.0  for  checking  prior  to  release  to  payload/subsystem  - 

same  problem  as  above. 
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3.  Trust  user:  He  states  that  his  program  does  not  include 

constrained/restricted  operating  modes  and  he  will  label  all  his 
commands  in  the  "OPEN"  (e.g.,  ASCII  encoded)  for  Function  3.0 
checking — still  have  the  problem  of  l.b  above  even  if  you  can  trust 
the  user. 

4.  Implement  "electronic  key"  that  Function  3.0  uses  to  "unlock" 
resources  associated  with  user's  requested  mode  of  operation 
specified  in  the  OEL . 

Command  Management  — Restricted  Operation 

It  is  expected  that  the  NASA  safety  community  will  require  an  independent 
safety  control  function  for  all  restricted  operations  and  for  this  reason 
option  4 above  (electronic  key)  is  selected  for  restricted  command  management; 
Function  3.0  unlocks  resources  required  for  restricted  operations  and  the  user 
does  not  solely  control  these  resources.  (It  can  also  be  expected  that 
mechanical  locks/stops,  locked/guarded  safety  switches,  procedural  operations, 
and  other  non-electronic  management  concepts  will  also  be  employed.) 

Command  Management  - Constrained  Operations 

Constrained  operations  do  not  affect  safety  and  option  3 above  is  acceptable. 
The  recommended  implementation  is  that  payloads  report  their  mode  of  operation 
at  all  times  (when  they  are  powered  ON)  to  Function  3.0  at  a rate  of  between  1 
1/sec  and  1/min.  If  a payload  enters  a constrained  mode  and  reports  it,  or  it 
does  not  report  its  operating  mode  at  the  required  interval  (e.g.,  software 
"bug"  may  have  resulted  in  a branch  to  an  undefined  operating  mode)  then  the 
payload  will  be  powered  OFF  and  the  event  will.be  recorded  in  the  archives  and 
also  distributed  via  an  ancillary  data  FLAG  which  alerts  all  users  of  the 
possible  interference  problem  (recall  that  safety  is  not  an  issue  in 
constrained  operations).  The  flag  will  contain  adequate  information  to  route 
subsequent  inquiries  to  the  source  and  the  time  at  which  the  anomaly  occurred. 


The  risk  in  this  approach  is  that  a payload  will  enter  a constrained  mode  of 
operation,  and  not  report  it  to  Function  3.0,  thereby  jeopardizing  the  quality 
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of  data  being  captured  by  other  payloads.  This  risk  is  minimized  by 
implementing  NASA  procedures  for  validating  the  reporting  system  during 
qualification/acceptance  testing  of  payloads. 

Command  Management  - Resource  Allocation 

As  discussed  earlier,  payloads  will  require  different  resources  for  its 

operating  modes.  If  a payload  is  powered  OFF,  an  activation  command 
will  be  routed  to  Function  3.0  which  puts  the  command  in  the  OEL  along  with 

the  resource  (specified  in  RSCRCS)  required,  and  whether  it  is  for  immediate 
or  future  execution,  as  discussed  earlier.  Thereafter,  commands  will  be 
routed  directly  to  the  payload  with  no  checking  required. 

4. 5.8.2  Command  Management  - Core  Operations 


The  management  of  commands  to  core  subsystems  are  in  a special  category  since 
subsystems  are,  in  general,  continuously  active  and  may  be  required  to  provide 
normal  services  (e.g.,  attitude  control)  in  parallel  with  diagnostic  or  other 
operations.  Subsystems  are  also  special  since  they  are  developed  and  operated 
by  NASA,  as  opposed  to  a customer,  and  must  endure  for  the  life  of  the 
program.  This  last  requirement  will  justify  the  development  of  large  scale 
expert  system  command  checkers  whose  cost  can  be  "amortized"  over  the  life  of 
the  program.  Predictive  command  checking  via  expert  system  checkers  will  form 
the  basis  for  core  command  management 

Because  of  the  complex  and  time-dependent  interaction  between  certain 
subsystems  or  even  within  a single  subsystem,  commands  must  be  rejected  (e.g., 
turn  OFF  the  life  support  system,  VENT  a crew-occupied  module,  CLOSE  oxygen 
valve  to  a crew-occupied  module,  ...)  based  on  the  physical  location  of  crew 
personnel  and  numerous  other  SSPE  state  parameters.  This  leads  to  the 
definition  of  yet  another  vector  called  SS  STATE  which  is  defined,  by  example, 
in  Figure  4. 5. 8-1.  The  basic  procedure  for  managing  core  commands  requires 
the  following  steps  for  implementation: 

1.  Predefine  all  possible  macro-  and  micro-commands,  where  a command  is 
designated  as  CMMD^[  ],  i = 1,  2,  ...,  L.  The  integer  L indicates 


4-86 


the  total  number  of  commands  and  the  brackets  indicate  parameters  or 
arguments  of  the  command. 

Prior  to  executing  any  arbitrary  command  perform  a predictive  test  to 
determine  the  executabi lity  of  the  command  given  the  current  SSPE's 
state  vector  using  the  previously  mentioned  expert  system  checker. 


An  Ordered  Set  of  Not  Necessarily  Numerical  Components  that  at  Any  Instant  of  Time 
Characterize  the  State  of  an  SSPE  to  the  Degree  Required  to  Implement  a Command 
Management  System. 

SS  State  = (d„  d2 dm) 

= (Payload  Status,  Subsystem  Status,  Crew  Status,...) 
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Figure  4.5.8-1.  SSPE  State  Vector  Definition 


The  end-to-end  flow  of  core  commands  is  shown  in  Figure  4.5. 8-2  which  also 
illustrates  the  concept  of  a core  operator  in  a hierarchy  of  authorized 
operators  that  are  allowed  to  transmit  certain  classes  of  commands. 

4.5.9  Example  of  Payload  Command  Management 

An  example  of  command  management  is  shown  in  Figures  4. 5.9-1  and  4. 5. 9-2  for  a 
hypothetical  payload  TDM  XXXX.  An  electronic  key  is  used  to  control  the  prime 
power  resources  to  the  high-  and  low-voltage  laser  power  supply.  In  this  case 
the  user  may  enter  the  restricted  mode  (via  restricted  command  that  he  issued) 
but  no  emission  from  the  laser  is  generated  and  no  hazardous  operation 
results.  Since  he  is  reporting  his  mode  to  Function  3.0,  he  will  be  alerted 
and/or  disconnected. 
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SSPE  Control  Center  | SSPE 


Figure  4.5.8-2.  Core  Command  Checking 


Laser  Off Laser  On 


Disconnect  Rule  | 


For  i = 1,2,3 
If  T,  Tschednegotjated 
Then  Disconnect  Payload 


Figure  4.5.9-1.  State  Diagram  - Hypothetical  Payload  TDM  XXXX 
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Figure  4.5.9-2.  Block  Diagram  - Hypothetical  Payload  TDM  XXXX 


4.5.10  Command  Management  Scenarios 

Numerous  scenarios  should  be  developed  to  validate  the  command  management 
system  previously  described.  Parameters  that  generate  ideas  for  scenario 
sequences  include: 

1.  Manned/unmanned  SSPE's. 

2.  Onboard/Ground  Operator/Customer . 

3.  Payload  Duty  Cycle:  100%/under  100%. 

4.  Maintenance,  diagnostics,  payload  integration,  buildup,  ... 
operations . 

5.  Typical  Core  Operations  - reboost,  OMV/OTV  operations,  ...  . 

6.  Ground/Onboard  interaction  during  hazardous  operations  - fueling, 
docking,  ...  . 

7.  Unmanned  SS  operations. 
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Only  one  scenario  is  considered  at  this  time  and  it  is  developed  in  the 
remaining  subparagraphs. 


4.5.10.1  Scenario  No.  1:  Payload  Operations  for  COM  1234 

In  this  scenario  a customer  is  defined  that  operates  from  a POCC  or  from  his 
own  facility  (he  is  mobile)  and  he  has  a payload  (COM  1234  in  the  SS)  that 
operates  with  a duty  cycle  of  less  than  100%.  The  payload  has  been  qualified 
by  analysis,  test  and  inspection  procedures  (conducted  by  the  customer  and 
witnessed  by  NASA)  to  operate  in  these  three  modes  (which  are  the  basis  for 
command  management): 

1.  Mode  1 — COM  1234  is  powered  ON  and  will  execute  software  transmitted 
via  telecommand  or  accessed  from  the  onboard  mass  store.  Used  for 
integration  of  new  software  modules  and  other  miscellaneous  functions. 

2.  Mode  2 - The  data  acquisition  electronics  (principally  the  DC  offset 
and  non-linearity  in  the  A/D  converter)  are  calibrated  using  a 
low-power  stimulus;  while  presenting  no  safety  or  damage  hazard,  it 
has  a spectral  emission  that  interferes  with  payload  COM  5678  and 
hence  places  a constraint  on  the  simultaneous  operations  of  these  two 
payloads . 

3.  Mode  3 - Used  for  acquisition  of  quick-look  and  production  data  and 
has  constraints  and  restrictions  placed  on  its  operation. 

In  the  definition  of  this  payload  to  the  SSIS/SSDS,  the  resources, 
constraints,  and  restrictions  are  specifically  characterized  and  quantified 
for  each  of  the  three  modes.  In  addition,  the  payload  will  be  required  to 
report  its  operating  mode  to  Function  3,0  so  that  constrained  operations  can 
be  discontinued.  To  implement  this  reporting,  COM  1234  will  be  required  to 
measure  parameters  in  its  I/O  section  that  confirm  (even  in  the  presence  of  a 
single  failure)  the  ON/OFF  status  of  the  low  power  (Mode  2)  and  high  power 
(Mode  3)  stimuli.  Recall  that  Function  3.0  is  relying  on  the  payload  to 
correctly  report  its  mode  but  in  all  cases  has  an  independent  electronic  key 
controlling  the  restricted  operations  conducted  in  Mode  3. 


4-90 


On  a particular  day  the  customer  is  at  the  POCC  and  logs  in  for  payload  COM 
1234.  He  is  authenticated  and  a menu  of  options  is  displayed  on  his  terminal 
as  follows: 


SOFTWARE  DEVELOPMENT 
SCHEDULE  OPERATIONS 
PAYLOAD  OPERATIONS 

He  selects  the  last  option  and  is  given  a status  summary  of  his  payload  as 
follows : 

COMM  1234  IS  CURRENTLY  POWERED  OFF. 

NEXT  SCHEDULED  ACTIVITY  IS  AT  TIME 
04:00:12  AT  LAT  XXX  AND  LONG  YYY 
FOR  A DURATION  OF  12  MINUTES 

The  customer  wants  to  activate  his  payload  for  calibration  only,  to 
investigate  some  anomalies  he  has  observed  in  previously  acquired  data.  He 
estimates  that  approximately  45  minutes  will  be  required  for  this  activity  so 
he  will  request  one  hour  of  activation  time  in  the  CALIBRATE  mode. 

Calibration  for  COM  1234  is  not  automated  and  the  customer  will  necessarily 
interact  with  the  payload  to  implement  the  calibration  procedures.  COM  1234 's 
production  data,  however,  is  acquired  automatically  and  the  customer  need  not 
be  involved  (at  his  option)  in  this  operation.  Onboard  implemented  functions 
3.3  and  3.4  will  automatically  sequence  COM  1234  ON,  the  next  time  which  will 
be  at  04:00:12  corresponding  to  coordinates  LAT  XXX  and  LONG  YYY,  and  will 
automatically  sequence  down  the  payload  after  the  12  minute  production  data 
acquisition  cycle  is  completed. 

The  customer,  interacting  with  the  POCC-resident  software  develops  an 
activation  command  that  specifies  the  following: 

MODE:  CALIBRATE 

TIME  ON:  60  MINS 

START  TIME:  IMMEDIATE 
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The  command  is  transported  from  the  POCC  via  the  following  transparent  (to  the 
customer)  operations. 


1.  A session  is  established  with  the  SS  Control  Center  (CC)  using  option 
1 in  Figure  4.5.10-1.  In  this  option  the  POCC  is  a node  in  an  X.25 
circuit  providing  network  services  (lower  3 OSI  layers)  to  the  CC. 

2.  After  the  connection  is  completed,  the  command  is  transmitted  and 

will  be  automatically  processed  in  the  CC.  The  CC  has  knowledge  of 
the  operating  modes  of  COM  1234  and  retrieves  from  local  memory  the 
triplet  T (CALIBRATION)  that  specifies  the  resources,  constraints  and 
restrictions  associated  with  the  calibrate  mode  of  operation.  The 
scenario  splits  into  two  scenarios  (A  and  B)  at  this  point:  GO  TO 

3. A for  the  completion  of  scenario  A and  to  3.B  for  the  next  step  in 
scenario  B. 


Option  J 

Interactive 

Operations 


Figure  4.5.10-1.  Communication  Interfaces  for  Scheduling 
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3A.  The  CC  has  determined  by  a simple  scan  of  the  OEL  and  the  current 

operating  mode  that  T (CALIBRATION)  for  COM  1234  can  be  satisfied  for 
the  next  60  minutes:  the  payload  can  be  immediately  attached  to  all 
required  resources  and  no  restriction  or  constraints  exist  for  this 
time  period.  The  customer  is  notified,  the  onboard  OEL  is  updated 
for  immediate  activation  of  COM  1234  (the  onboard  crew  is  audibly 
alerted  that  a OEL  adjustment  has  been  made  but  this  class  of  change 
does  not  require  their  approval  — the  audible  is  an  indication  of  a 
"fo*  information-only"  type  change).  At  this  point  two  seconds  have 
elapsed  since  step  1 was  initiated. 

3B.  At  the  CC  the  onboard  in— progress  operations  are  scanned  and  it  is 

determined  that  the  resources  are  available,  there  is  no  restriction, 
but  that  a constraint  exists  (COM  1234  has  a spectral  emission  in  the 
CALIBRATE  mode  that  interferes  with  COM  5678).  It  is  further 
determined  that  the  constraint  will  dissappear  in  12  minutes  when  COM 
5678  is  scheduled  to  be  deactivated,  but  then  there  will  be  a 
resource  limitation  in  power.  At  this  point  two  seconds  have  elapsed 
since  step  1 was  initiated. 

4B.  Several  options  for  future  activity  must  now  be  considered  since  COM 
1234  does  not  have  the  priority  to  adjust  current  in-progress 
operations  and  near  future  operations. 


5B.  The  scheduling  operator  at  the  control  center  (see  Figure  4.5.10-1) 
will  interact  with  the  scheduling  program  to  develop  an  agreed- to 
future  schedule  (scheduling  is  not  a fully  automated  function).  This 
interaction  with  the  customer  will,  in  general,  be  all-electronic. 

The  customer  at  the  POCC  is  informed  that  immediate  attachment  of  COM  1234  is 
impossible  based  on  his  priority  (priority  adjustments  are  possible  via  voice 
telecommunications  through  the  NASA  hierarchy).  The  customer  now  interacts 
through  his  terminal  examining  the  attach  options  sequentially  presented  to 
him  in  a menu  similar  to  the  way  customers  consider  and  select  airline  flight 
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options.  The  scheduling  operator  in  the  SSCC  develops  options  for  the 
customer  (after  they  are  computer  validated  in  terms  of  resources, 
constraints,  and  restrictions) . "Limited"  changes  are  authorized  to  be  made 
in  the  CC  without  onboard  crew  approval,  however,  voice  communications  with 
the  SS  commander  will  be  required  for  approval  of  certain  options  prior  to 
their  being  presented  to  the  customer. 


ATTACH  PROCEDURE  IMPLEMENTATION 


This  scenario  is  common  to  most  payload  operations.  The  Operating  Events  List 
(OEL)  is  the  master  source  for  primary  onboard  sequencing  (secondary 
sequencing  is  initiated  from  subsystems  or  payloads)  and  identical  copies 
reside  onboard  and  in  the  SSPEs  CCs . The  OEL  was  described  earlier  and  is 
shown  in  Figure  4.5.10-2  as  residing  in  Function  3.3  and  is  the  driving  source 
for  Function  3.4,  as  a function  of  time.  When  the  time  of  execution  for  a 
command  has  been  reached,  the  triplet  RSCRCS,  CONSTR,  and  RESTRICT  are 
revalidated  against  the  current  actual  operating  mode  and  then  passed  to 
subfunction  3.4.1  and  3.4.2  for  execution.  Resources  for  restricted 
operations  are  unlocked  (as  required)  and  attached  in  the  required  sequence 
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Figure  4.5.10-2.  Payload  Sequencing 
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(e.g.,  ATTACH  TCS  (COM  1234),  IF  TEMP  LESS  THAN  Tl,  THEN  ATTACH  POWER  (COM 
1234),  IF  CURRENT  (COM  1234)  LESS  THAN  II,  THEN  ...)• 


Since  COM  1234  has  been  powered  OFF  (duty  cycle  less  than  100%),  then  when 
powered  ON  it  will  automatically  boot-up  via  EPROM-embedded  code  and  then 
self-test  and  self-initialize  itself  to  become  an  addressable  entity  on  the 
payload  LAN  (this  payload  has  a dedicated  point-to-point  data  link  to  C&T  for 
the  primary  sensor  but  is  mode  controlled  via  the  LAN). 

Function  3.4.2  (see  Figure  4.5.10-2)  indirectly  activates  Function  4.2.5. 1 
(see  Figure  4.5.10—3)  which  is  distributed  between  onboard  and  ground  and  from 
information  in  the  OEL  connects  all  of  the  onboard  entities  (binds  into 
sessions)  required  to  support  COM  1234' s commanded  operation. 

At  this  point  in  the  development  cycle  of  a command  management  system,  the 
ground  elements  are  assumed  to  be  open-loop  controlled  via  the  OEL  and  no 
formal  REQUEST/ ACKNOWLEDGE  message  interchange  for  ATTACHMENT  is  required. 

The  SSPE's  CC  coordinates  with  the  various  ground  components  to  support  the 
OEL  and  has  a permanent  session  with  onboard  function  4.2.5. 1 to  indicate  when 

a required  ground  resource  will  not  be  available  to  support  the  OEL. 

- - 

Function  4.2.5.1  Communication  Network  Control 
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5.0  COMMUNICATIONS  ASSUMPTIONS  AND  TRAFFIC  ANALYSIS 


The  purposes  of  this  section  are  to  define  the  communications-related 
assumptions  that  have  been  made  in  the  process  of  defining  an  SSDS 
architecture  and  to  summarize  the  methodology  and  results  of  a communications 
traffic  analysis.  The  assumptions  are  necessary  because,  at  this  early  stage 
of  the  Space  Station  program,  many  design  and  operating  features  external  to 
the  SSDS  have  not  been  defined.  The  communications  traffic  analysis  provides 
an  estimate  of  total  traffic  load  on  Space  station  communication  links  taking 
into  account  the  best  available  definition  of  mission  requirements , core 
requirements , and  operational  scenarios. 

The  key  results  of  this  traffic  analysis  are  summarized  below: 

• A single  TDRSS  SA  channel  has  sufficient  capacity  to  support  the  IOC 
Space  Station  program. 

• The  allocation  of  two  (or  more)  SA  channels  to  the  Space  Station 
Program  would  reduce  scheduling  competition  between  the  Space  Station 
and  the  platforms. 

• The  S-band  and  Ku-band  services  in  the  SA  channel  allocation  offer  an 
attractive  way  to  keep  core  and  customer  communications  traffic 
functionally  separated  and  to  also  provide  a level  of  redundancy  for 
critical  communications. 

• The  growth  scenario  indicates  that  the  currently  planned  TDRSS  SA 
capability  may  be  inadequate.  However,  there  is  significant 
uncertainty  in  the  mission  model  and  operational  scenario,  especially 
with  respect  to  foreign  payloads,  for  the  growth  time  period. 

• Video  communicator!  requirements  will  be  a significant  factor  in  the 
total  communications  traffic.  There  is  a need  to  improve  the 
definition  and  understanding  of  the  uses,  timelines  and  quality 
requirements  associated  with  this  video  traffic. 
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5.1  Assumptions 


A set  of  assumptions  has  been  developed  to  support  the  communication  traffic 
analysis  and  as  a basis  for  the  overall  SSDS  architecture  development.  Tor 
convenience,  these  are  categorized  as  (1)  TDRSS  utilization  assumptions,  and 
(2)  traffic  analysis  assumptions.  The  assumptions  are  intended  to  be 
consistent  with  the  set  of  references  listed  in  Table  5-1.  In  addition, 
internal  team  member  work  (e.g..  Shuttle  television  system),  and  informal  NASA 
sources  were  used  as  background  material. 

5.1.1  TDRSS  Utilization/Capability  Assumptions 

1.  The  SSDS  design  should  be  compatible  with  allocation  of  either  1,  2,  or  3 
SA  channels.  Figure  5-1  uses  two  examples  to  clarify  this  assumption. 

2.  All  Space  Station  data  on  TDRSS  channels  is  digital. 

3.  The  peak  uncoded  channel  capacities  for  the  TDRSS  KSA  service  are  25  Mbps 
(forward)  and  300  Mbps  (return);  the  peak  SSA  channel  capacities  (with 
coding)  are  300  Kbps  (forward)  and  3 Mbps  (return). 

4.  Convolutional  coding  will  probably  not  be  used  on  the  KSA  return  link, 
lhe  Space  Station  requirement  for  a 10 ’6  maximum  Bit  Error  Rate  and 
application-specific  requirements  for  a lower  BER's  can  be  met  with  lower 
overhead  codes,  such  as  a Reed-Solomon  block  code. 

5.  One  candidate  partitioning  of  the  communications  traffic  is  shown  in  Table 
5-2.  Space-to-ground  and  ground-to-space  communications  traffic  for  the 
Space  Station  manned  core  is  allocated  to  the  SA  services.  This  candid  .!. c 
allocation  puts  core  traffic  on  the  SSA  links  and  payload  traffic  on  the 
KSA  links,  with  voice  and  video  being  on  both  links.  The  capacity  for  ! ho 
SSA  links  to  handle  the  core  video  traffic  is  doubtful;  the  KSA  links  will 
have  to  be  used.  Other  candidate  partitions  of  the  communications  traffic 
can  be  identified,  but  this  one  (above)  appears  to  be  an  attractive 

al local i on . 
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6 The  Space  Station  (manned  core)  and  the  COP  will  be  designed  so  that  the 
COP  can  either  access  TDRSS  directly  or  can  use  the  Space  Station  as  a 
relay.  Although  the  use  of  Space  Station  as  a relay  and  buffer  has 
advantages  for  TDRSS  utilization  efficiency  and  for  COP  system  design,  'he 
COP  needs  to  have  an  independent  TDRSS  capability  to  allow  it  to  operate 
beyond  the  Space  Station  line -of-sight . This  will  aPfect  the  complexity, 
cost  and  power  required  for  the  onboard  COP  communications  system. 
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9.  RFP  and  Corollary  documents  for  the  OMV . 
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Figure  5-1.  Example  TDRSS  Allocations 

Table  5-2 

Allocations  to  TDRSS  Channels 


KSA-F  KSA-R  SSA-F  SSA-R 

PAYLOAD  CMDS  & UPLINK  DATA  X 

PAYLOAD  MISSION  DATA  X 

PAYLOAD  HEALTH  & SAFETY  DATA  X X 


CORE  CMDS  & UPLINK  DATA  X (backup)  X (prime) 

CORE  ENGINEERING  DATA  X X 

VOICE  X X X X 

VIDEO-HIGH  RATE  X X 

VIDEO-LOW  RATE  X X X X 


5-4 


5.1.2 


Traffic  Analysis  Assumptions 

1.  The  Langley  mission  data  base,  as  modified  and  extended  by  the  Woods  Hole 
Workshop  and  by  SSDS  team  analysis,  represents  the  mission  requirements , 

2.  The  crew  size  growth  profile  is  as  shown  in  Table  5-4.  This  assumes  a 
step  increase  from  6 to  12  during  year  3 based  on  IVA  man-hour  growth  <md 
a final  step  to  a crew  size  of  18  in  year  7. 

3 . EVA  man-hours  per  week  are  an  average  based  on  the  EVA  man-hours  per  year 
specified  in  reference  1. 

4.  The  STS  docking  traffic  is  one  Orbiter  per  90  days  for  every  6 crewmen. 

5.  OMV  and  OTV  events  are  per  reference  1.  Each  event  provides  communication 

traffic  for  8 hours. 

6.  The  number  of  free-flyers  grows  from  0 to  8 as  shown  in  Table  5-4. 

7.  MRMS  operating  hours  per  week  is  equal  to  1/3  of  the  EVA  hours  plus  1 hour 

per  OMV  or  OTV  event. 

8.  Surveillance  video  time  is  4 hours/day  per  IOC  crewman  plus  2 hours/day 
for  each  additional  crewman. 

9.  The  IOC  core  command  and  engineering  telemetry  rates  are  4 Kbps  and  256 
Kbps,  respectively,  and  increase  as  the  crew  size  increases  as  shown  in 
Table  5-4. 

10.  Training  time  is  1/2  hour/day  per  crew  member. 

11.  Recreation/leisure  time  is  1/2  hour/day  on  working  days,  2 hours/day  on 
non-working  days,  for  each  crew  member. 

12.  Video  communications  are  assumed  to  be  in  three  categories:  (1)  full, 
resolution,  full-motion  commercial  TV  quality,  (2)  freeze-frame  video,  and 
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(3)  an  in-between  quality  with  full  resolution  and  slow  frame  rate.  These 
video  signals  are  assumed  to  be  encoded  and  compressed  into  22  Mbps,  400 
Kbps,  and  4.5  Mbps  data  streams,  respectively.  An  extension  of  this 
assumption  is  that  the  400  Kbps  video  is  adequate  to  support  the  OMV 
teleoperation  activity.  Thi-s  assumption  is  based  on  our  interpretation  of 
OMV  documents.  A brief  discussion  of  these  rates  and  the  corresponding 
rationale  is  provided  in  paragraph  5 3.1. 

5.2  Methodology 

5.2.1  Scenario  Development 

The  Space  Station  Traffic  scenarios  were  derived  from  various  operational 
functional  modes  as  now  understood,  and  included  the  following:  EVA,  orbiler 

docking  and  undocking,  OMV  operations,  OTV  operations.  Free  Flyer  operations, 
co-orbiter  operations,  MRMS  operations,  internal  and  external  surveillance 
video,  core  systems,  training,  recreation  and  leisure,  and  attached  or 
internal  experiments. 

These  scenarios  were  then  individually  examined  to  develop  a time  and  use 
baseline  which  required  interpretation  of  various  documents,  assumptions  where 
necessary,  and  then  linking  that  to  the  specific  data  rates  for  each  class  of 
traffic.  For  example,  in  the  surveillance  scenario,  our  baseline  assumed  shat 
there  would  be  fifteen  internal  cameras  used  to  monitor  most  aspects  of  the 
interior  spaces  of  the  station  and  crew  actions  and  docking  ports,  as  well  as 
two  cameras  used  to  monitor  the  external  structure.  Our  thinking  has  been 

changed  as  a result  of  some  discussions  at  the  Prox  Ops  workshop  in  February 
1985,  since  it  was  indicated  that  up  to  18  external  surveillance  cameras  will 
probably  be  required.  (The  effect  of  that  information  on  the  overall 
communications  profile  has  not  been  incorporated  at  this  point.) 

For  purposes  of  further  explaining,  the  following  is  a sample  discussion  using 
a surveillance  scenario.  Several  assumptions  were  made:  a 10%  duty  cycle  mas 

assumed  in  terms  of  video  use  related  to  communications  downlink  use;  thus, 
for  15  internal  surveillance  cameras,  the  equivalent  of  1.5  full  time  video 
channels  was  assigned  for  this  group,  and  the  same  rationale  was  used  for  the 
external  cameras.  It  was  also  assumed  that  there  would  be  increased  use  of 
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the  internal  cameras  based  on  an  increase  in  the  crew  size,  since  there  would 
be  more  crew  activity. 

The  crew  growth  was  based  on  the  following:  a)  the  RFP  indicates  an  IOC  crew 

size  of  six  and  a crew  size  not  to  exceed  eighteen,  b)  in  order  to  determine 
the  steps  in  crew  increase  and  the  point  of  increase,  information  in  the  RFP 
on  increases  in  crew  activity  was  used.  An  indirect  indicator  was  derived 
from  the  step  functions  in  crew  medical  data  (from  Langley  documents).  The 
changes  implied  a crew  change  (six  to  twelve)  in  the  third  year,  while 
achieving  maximum  crew  size  during  the  seventh  year  (see  Table  5-4,  Crew 
Distribution).  Finally,  the  use  scenario  was  related  to  communications 
bandwidth/data  rates  by  assuming  that  a slow  scan  TV  algorithm  could  be  used 
for  "normal"  surveillance.  The  use  of  4.5  Mbps  rate  represented  a reasonable 
quality,  (NTSC)  full  color  picture,  which  uses  a 'slow  scan"  frame  rate  of 
five  frames/so- >md . 

52.2  Communication  Profile  Development 
Space  Station 


The  time  related  communications  profile,  as  presented,  is  based  on: 

a)  a broad  scenario  for  each  functional  mode  related  to  the  C&T  system; 

b)  attempting  to  quantify  the  scenario  from  explicit  or  implicit  sources; 

c)  developing  assumptions  on  gray  areas,  which  relate  to  operational  use 
considerations  or  reasonableness  and  reviewing  some  of  these 
assumptions  in  areas  of  major  criticality  (e.g.,  the  major 
Communication  bandwidth  drivers)  with  customer  and  study  ' . ,un 
personnel ; 

d)  assigning  rates  to  each  source  or  sink  which  eventually  contributes 
to  the  KSA/TDRSS  down  link  based  on  the  Woods  Hole  projections  for 
the  experiments,  recommended  rates  for  digital  video  where  these  are 
explicit  in  NASA  related  documents  or  based  on  filtering  of 
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discussions  with  NASA  personnel,  and  assumptions  on  quality  and 
adequacy  of  pictures; 


e)  some  attempts  at  scheduling  transmission  to  the  ground  where  any 
specific  operational  scenario  reasonably  allows  that,  in  order  to 
smooth  out  peak  short  term  (seconds  or  minutes)  demands  on  the 
communications  resources;  a generic  unit  period  was  used  as  the  bus  is 
for  the  link  utilization. 

f)  placing  the  resultant  profile  into  two  time  frames  (IOC  and  "growth") 
and  comparing  each  against  the  KSA  bandwidth  constraints. 


The  assumption  used  for  the  traffic  analysis  was  that  the  COP  would  generally 
be  in  view  of  the  Space  Station,  and  that  both  uplinked  (program  loading  und 
commands)  and  downlinked  (experimental  data,  video,  and  health/status 
telemetry)  information  would  go  through  the  Space  Station. 

POP 


The  information  on  this  is  derived  from  the  Woods  Hole  Workshop  data  base  and 
attendant  experiments/sensors  and  it  is  assumed  that  Polar  Orbiters  would 
access  TDRSS  (KSA  Channel)  directly. 

5 • 3 Detailed  Strawman  Scenario  Development 

Detailed  Strawman  communications  system  connectivity  and  link  loading 
scenarios  were  developed  for  several  Space  Station  related  activities  to 
provide  a basis  for  a composite  traffic  profile  analysis. 
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Those  scenarios  are  as  follows: 


1) 

LVA 

2) 

Orbiter  Docking/Undocking 

3) 

OTV/OMV 

4) 

Free  Flyer 

5) 

mm 

6) 

Surveillance  (Internal  & External) 

/) 

Telemetry  Command  & Control  (Core  Systems) 

8) 

Training 

9) 

Recreation 

10) 

Internal/ Attached  Payloads 

11) 

Co-Orbiting  Platform  (COP) 

12) 

Polar-Orbiting  Platform  (POP) 

1 

Standardization  of  Communications  for  use  in 

Scenarios 

Assuming  digitization  of  all  communications  with  elements  external  to  the 
Space  Station,  several  standardized  methods  of  representing  communications  in 
the  Scenarios  were  used. 

The  audio  and  video  data  rates  used  as  standard  throughout  the  scenarios  are 
presented  in  Table  5-3.  These  rates  were  from  NASA  sources  such  as  documents, 
contracted  studies,  and  discussions  with  NASA  personnel.  Other  possible 
options  for  audio  and  video  (not  used)  include:  1)  64  kbps  voice  channels  fur 

high  quality  speech  recognition;  2)  25  Mbps,  or  higher,  video  data  rates  for 
high  resolution  compressed  video  or  uncompressed  video;  3)  1.544  Mbps 
compressed  video  with  T1  communication  link  compatibility;  or  56  kbps  for 
teleconference-quality  video.  Other  data  rates  used  in  the  scenarios,  such  as 
command  and  telemetry,  were  selected  or  derived  from  the  Space  Station 
references  identified  in  Table  5-1. 
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Table  5-3. 

Audio  and  Video  Data  Rates  used  in  Traffic  Profile 


• AUDIO 

-STS  ORBITER 
-ALL  OTHER  AUDIO 


REFERENCE  (Table  5-1) 

32  KBPS  (1) 

16  KBPS  (1),  (10) 


VIDEO 


-COMPRESSED  SLOW  SCAN  TV  400  KBPS 
-FREEZE  FRAME  TV  400  KBPS 

-NTSC,  COMPRESSED  22  MBPS 

-NTSC,  COMPRESSED  4.5  MBPS 


(9) 

(2) 

(10) ,  (5) 


(1) 


The  digital  video  rates  which  have  been  selected  should  not  be  considered  as 
final  rates  to  be  used  for  the  space  station  for  either  external  or  internal 
communications.  These  rates  are  only  goals  that  are  being  considered  for 
digital  video.  However,  it  is  useful  to  consider  how  the  22  mbp:-  ui«s 
selected,  as  an  example  of  how  the  rates  were  selected. 


One  reference  was  an  article  by  fu,  Teasdale,  Zimmerman,  "A  Communicat  i.or\ 
system  conceptual  design  for  a low  earth  orbiting  manned  space  station"  (NIC 
1982)  which  assumed  22  Mbps  for  quality  video.  The  Reference  Configured  ion 
uses  the  value  25  Mbps  for  compressed  NTSC  quality  video.  At  this  point  in 
time  during  a conceptual  analyses  the  difference  between  22  and  25  Mbps  in  not 
particularly  significant. 

RCA,  under  contract  to, NASA  has  been  studying  27/28  Mbps  digital  video  for  use 
on  the  space  shuttle  orbiter,  using  a compression  algorithm. 


Before  a truly  definable  digital  video  rate  can  be  finalized,  the  compression 
algorithm  must  be  selected.  The  selection  of  an  algorithm  will  be  dependent 
on  several  factors  which  include  but  are  not  limited  to: 


1)  quality  of  image 

2)  speed  of  algorithm 
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3)  volume,  power,  weight  requirements  of  compression  processor  and  that 
of  the  transmission  equipment 

4)  cost 

5)  definition/resolution  of  image,  and 

6)  operational/mission  needs 

At  the  current  time,  it  appears  to  be  technically  reasonable  and  consistent 
with  other  NASA  sponsored  activity  to  use  22  Mbps  as  the  rate  for  compressed, 
NTSC  quality  video. 


In  order  to  graphically  portray  traffic  profiles  and  to  classify  data  for 
analysis,  three  symbolic  signal  distributions  were  used  to  represent  various 
types  of  data  in  the  analysis.  As  portrayed  in  Figure  5—2  data  generated 
during  a unit  time  period  (arbitrary  length  of  time)  can  be  represented  by 
different  distributions.  A uniform  representation  over  a unit  period  of  time 
represents  a continuous  and  constant  data  rate  for  the  duration  of  the  event 
or  activity  under  consideration.  For  example,  OMV  telemetry  rate  is 
anticipated  from  an  OMV  while  under  control  of  the  Space  Station.  A 
triangular  representation  is  used  for  data  generation  for  which  the  data  rate 
will  vary  over  a period  of  time,  T.  A pulse  representation  is  used  for 


constant  rate  data  generation  which  occurs  only  for  a fraction  of  the  lime 
period  in  question. 
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5.3.2 


Detailed  Strawman  Scenari o s 


Figures  5—3  through  5—14  portray  the  12  strawman  communications  scenarios. 
Each  was  designed  to  support  the  Space  Station  mission  requirements  and  be 
consistent  with  requirements  outlined  in  the  Space  Station  Reference 
Configuration  and  Space  Station  SOW,  (Ref.  1 and  2).  The  distribution  of  fit 
through  the  linked  systems  is  indicated  with  arrows  and  symbolic  plots  of 
signal  distributions. 

5.3.3  Space  Station  Activity  Intensity 

Table  5-4  lists  the  changes  in  activity  intensity  over  a period  of  years  from 
IOC  to  ten  years  into  the  Space  Station  Program.  Assumptions  and  References 
for  these  values  are  described  in  paragraph  5.1.2.  Because  the  Idlest 
information  available  on  payloads  does  not  provide  a year  to  year  listing  of 
payloads,  payload  quantities  are  given  only  for  IOC  and  a growth  year.  The 
growth  year  is  assumed  to  correspond  to  a year  shortly  after  year  6 or  year  7 
when  18  crewmembers  may  habitat  the  SS.  It  is  not  evident  from  sources 
whether  year  6/7  through  year  10  have  significantly  different  total  activity 
(i.e.,  some  activities  appear  to  increase,  other  appear  to  be  reduced). 

5.3.3. 1 US  Payloads  (Missions).  US  attached  payload  communications 
statistics  are  presented  in  Table  5-5.  The  highest  possible  data  rate  (fVak 
Data  Rate)  for  attached  payloads  is  433  Mbps  during  IOC.  The  Peak  Data  Rate 
was  determined  by  adding  up  the  data  output  rate  of  all  Payloads,  which  im  ms 
all  experiments  would  operate  simultaneously  to  provide  the  433  Mbps,  a 
demanding  upper  bound.  As  such,  the  Peak  Data  Rate  establishes  a max 'mum 
bound  for  data  loading  of  the  communications  distribution  system.  With  an 
average  data  rate  of  26  Mbps  for  the  33  IOC  payloads,  scheduling  .«nd 
interleaving  of  data  from  the  various  payload  experiments  should  allow  for  a 
more  realisti:  loading  on  the  communication  distribution  system  fluctuating 
around  an  average  rate  near  the  26  Mbps  figure. 

It  was  assumed  that  4.5  Mbps  TV  (5  frame/sec  compressed  NTSC  format)  ..uld 
support  the  payloads.  In  fact  many  payloads  may  require  lower  rate  TV  while 
other  may  require  higher  rate  TV. 
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Signals 


Figure  5-3.  EVA  Scenario 


0 1 0 1 


* — 2 Voice  Channels  to  Orbiter 


Figure  5-4.  Orbiter  Docking/Undocking  Scenario 
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Note:  Freeze  Frame  Video  May  Not  Be  Adequate 
for  Interactive  Robotic  Interface 


Figure  5-5.  OMV  Scenario 


Figure  5-6.  Free  Flyer  Scenario 
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Figure  5-7.  MR  MS  Scenario 


Internal  to 
Video  Network 


0 T T+0.1  1.0  0 1.0 

Figure  5*8.  Surveillance  Scenario 
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Signals 


Vary  Depending  On 
Video  Requirements 

Distribution 
Network 


Figure  5-9.  Telemetry  Command  Control  Scenario  (Manned)  For  Core  Systems 
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0 0.5  1 .0 


Internal  to 
Networks 

Video 


0 0.5  1.0 


Audio 


Figure  5-11.  Recreation/ Leisure  Scenario 


Command 


Telemetry 


Figure  5-12.  Internal/Attached  Experiment  Scenario 
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Signals 

Vary  Depending  on 


Figure  5-13.  Coorbiting  Platform  Scenario 


To  WSGT 


Signals 

Vary  Depending  On 
Requirements 


Figure  5-14.  Polar-Orbiting  Platform  Scenario 
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Table  5-4.  Summary  of  Space  Station  Activity  Growth  Scenario 
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POP  1 US  PAYLOADS  QUANTITY 


Table  5-5.  Attached  Payload  Statistics 


ATTACHED  PAYLOADS  SUMMARY 


Payload  Quantity 
Peak  Data  Rate 
Avg . Data  Rate 


IOC 

33 

433  Mbps 
26  Mbps 


GROWTH 

16 

402  Mbps 
51  Mbps 


P/L  Video 

Aug.  Rate  (4.5  Mbps  TV) 


61.8  Hrs/Day  80.2  Hrs/Day 

11.6  Mbps  15.0  Mbps 


ATTACHED  PAYLOAD  COMMUNICATIONS  DRIVERS 


IOC 

GROWTH 

DESTINATION 

TRIGGER 

DELAY 

PEAK 

AVERAGE 

(Mbps 

0 (Mbps ) 

X 

X 

com 

1014  Remote  Sensing 

Land 

24  Hrs. 

300 

2.5 

X 

SAAX 

0011  Adv.  Solar  Obs . 

Sun 

0 Hrs  . 

50 

31.25 

X 

SAAX 

0207  Solar  Terrestrial 

Sun 

0 Hrs. 

10 

2.5 

X 

SAAX 

0227  Plasma  Exp. 

Poisson 

0 Hrs. 

50 

16.7 

X 

TDMX 

2542  Tether  Const. 

Poisson 

W/A 

120 

20.0 

ATTACHED  PAYLOAD  VIDEO 

DRIVERS 

X 

SAAX' 

0009  Pinhole  Occult 

Sun 

24  Hrs. 

X 

SAAX 

0011  Adu.  Solar  Obs. 

Sun 

0 Hrs  . 

X 

X 

SAAX 

401  Micro  Gravity  Lab. 

Cont . 

3 Hrs. 

X 

X 

SAAX 

404  Materials  Lab 

Cont. 

3 Hrs  . 

N/A  = Wot  Available 
Reference  6 and  7 (Table  5-1) 
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Payload  communications  and  video  drivers  were  determined  to  support  the 
development  of  a composite  payload  data  profile.  Only  five  payloads  were 
found  to  have  a peak  output  rate  greater  than  1.5  Mbps  and/or  an  average  rate 
greater  than  1.0Mbps.  Four  payloads  were  found  to  generate  video  more  than 
two  hours  per  day . 

The  Trigger  and  Delay  characteristics  of  payloads  determine  when  the  payload 
is  assumed  to  generate  data  and  what  delay  for  delivery  of  data  (b.  She 
customer)  is  acceptable.  Triggers  are  of  four  types.  Some  payloads  are 
triggered  for  land  or  sun  observation  only.  If  the  payload  should  operate 
continuously  while  in  view  of  the  land  or  sun,  it  would  operate  33%  of  the 
time  for  land  or  approximately  62%  of  the  time  for  the  sun.  Other  pay1  .ds 
have  a continuous  trigger,  i.e.,  operate  continuously.  A fourth  trigger 
assumes  that  the  probability  of  a payload  operating  at  any  given  tinu*  is 
dependent  upon  a poisson  probability  distribution,  but  than  an  average  data 
rate  can  be  determined  over  a long  period  of  t line. 

Figure  5-15  presents  attached  payload  profiles.  These  profiles  portray  the 
most  likely  distribution  of  payload  data  rates  over  the  period  of  an  orbit, 
that  will  minimize  channel  bandwidth  at  all  times.  The  growth  profile  will  be 
used  as  an  example  to  show  how  a profile  is  determined.  Payload  COMM  101*  m 
accept  a 24  hour  data  delivery  delay,  so  to  minimize  communications  bandwidth 
the  average  2.5  Mbps  rate  is  used  over  the  full  period  of  time.  The  vide-  . an 
be  shown  at  an  average  rate  of  15.0  Mbps  because  all  but  one  of  the  video 


IOC  Growth 


Figure  5*15.  Attached  Payloads 
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drivers  will  accept  a three  hour  delay  or  more,  thus  allowing  throttl .1  <>j  of 
video  data  at  the  average  rate.  Because  payloads  SAAX  0011  and  SAAX  0227 
require  minimal  delay,  their  data  must  be  transmitted  at  the  generation  rate 
of  50  Mbps  for  the  fraction  of  time  these  payloads  operate.  The  partial 
overlapping  of  transmission  of  data  for  these  payloads  is  due  to  the 

independent  triggers  (sun  or  poisson)  for  the  payload.  Thus,  the  figure 
primarily  reflects  the  major  effects  of  SAAX  0011,  0227  and  COMM  1014  (f.  urn 
the  Woods  Hole  work),  the  timeliness  requirements  and  the  triggers.  Other 
experiments  contribute  little  to  the  loading. 

Uplink  communications  to  the  space  station  for  attached  payloads  are 
characterized  in  Table  5-6. 

As  indicated  in  Table  5—7  the  communications  for  the  Co— orbiting  Platform  are 
uniform  throughout  the  space  station  life  time.  The  Woods  Hole  data  base  <>nly 
presents  one  payload.  It  should  be  noted  that  the  previous  Langley  MRWG  data 
base  listed  several  payloads  for  th  COP. 


TABLE  5-6. 

Attached  Payload  TDRSS  Uplink  Command  and  Audio  Communications 


Simultaneous 
Average  Data  Rate 
Voice 

Avg.  Voice  Channels 

Avg.  Voice  Rate 

Combined  Ave.  (Voice  & Data) 


IOC 

51.1  kbps 
11.9  kbps 
60  Hrs/Day 
2.5 

40  kbps 
101  kbps 


GROWTH 

78.2  kbps 
12.4  kbps 
80  Hrs/Day 
3.3 

53  kbps 
131  kbps 


Reference  6 and  7 (Table  5-1) 
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Table  5-7 

Co-Orbiting  Platform  Payload  Statistics 


CO-ORBITING  PLATFORM  PAYLOADS  SUMMARY 

IOC  GROWTH 

P/L  QUANTITY  1 1 

DOWNLINK 

PEAK  DATA  RATE  1 Mbps  1 Mbps 

AVG.  DATA  RATE  1 Mbps  1 Mbps 

P/L.  VIDEO  0 Hrs.  0 Mrs. 

UPLINK 

PEAK  DATA  RATE  10  Kbps 

AVG.  DATA  RATE  .67  Kbps 

COP  PAYLOAD  COMMUNICATIONS  DRIVERS 

I°G  GROWTH  DESTINATION  TRIGGER  DELAY  PEAK  AVG_. 

(Mbps)  (Mbps) 

X X SAAX1  004  SIR  IF  Cont.  24  Hrs.  1.0  1.0 


Table  5-8  lists  the  statistics  on  the  3 Polar-orbiting  Platforms.  Because  the 
communications  drivers  for  each  platform  can  tolerate  a full  orbit  delay  (1.5 
hours)  or  more  in  delivery  of  data,  the  average  data  rate  is  adequate  for  the 
data  transmission  profile.  Figure  5-16  shows  the  projected  total  missies  H.-ita 
loading  of  TDRSS  return  links  for  the  SS,  COP,  and  POP's  (IOC  and  growth). 
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Table  5-8 


Statistics  for  Payloads  on  Polar— Orbiting  Platforms 


POP-1 

POP-2 

POP-3 

IOC 

GROWTH 

IOC 

GROWTH 

IOC  GROWTH 

P/L  QUANTITY 

10 

11 

11 

ii 

- 

4 

PEAK  DATA  RATE 

393  Mbps 

669  Mbps 

302  Mbps 

302  Mbps 

- 

76  Mbps 

AVG.  DATA  RATE 

80  Mbps 

154  Mbps 

18  Mbps 

18  Mbps 

- 

41  Mbps 

POP  COMMUNICATIONS  DRIVERS 


IOC 

GROWTH 

TRIGGER 

DELAY 

PEAK 

AVG . 

POP-1 

(Mbps) 

(Mbps ) 

X 

X 

COMM 

1019 

STEREO  IS 

LAND 

24  Mrs 

200 

54 

X 

COMM 

1020 

STEREO  IS/SAR 

LAND 

24  Mrs 

276 

75 

X 

X 

SAAX 

209 

HIRES 

LAND 

3 Mrs 

160 

22 

X 

X 

SAAX 

0228 

THERMAL  IR 

LAND 

3 Hrs 

30 

3 

POP-2 

X 

X 

SAAX 

0212 

SAR 

LAND 

6 Hrs 

300 

16 

POP-3 

- 

X 

COMM 

1023 

STEREO  SEA  SAR 

WATER 

1.5  Hrs 

76 

41 

REFERENCE  6 and  7 (Table  5-1) 
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Figure  5-16.  TDRSS  SA  Channel  Traffic  Versus  Capacity 

5 . 3 . 3 . 2 Foreign  Payloads  (Missions 


Tentative  foreign  payload  communications  drivers  are  presented  in  Table  5-9. 
They  are  considered  tentative  because;  1)  they  have  not  been  included  in  I he 
Woods  Hole  data  base  information  in  our  possession  as  of  this  writing;  2)  many 
details  on  the  payloads  are  missing  including  an  SSPE  allocation,  and  3) 
several  caveats  were  provided  in  the  document  (i.e.,  Ref.  7)  from  which  the 
data  was  taken.  One  caveat  was  that  many  foreign  payloads  duplicate  US 
payloads  and  may  not  need  to  be  listed  separately  in  later  listings  of 
payloads.  It  is  not  apparent  whether  this  means  there  are  multiple  similar 
experiments  (US  and  foreign)  or  time  phased  use  of  the  same  experimental 
equi,  m>nt. 

As  can  be  seen  in  Table  5-9  several  foreign  payloads  on  polar  platforms  could 
generate  data  at  rates  as  high  as  300  Mbps.  The  communications  loading  r, urn 
these  payloads  will  demand  more  of  the  TDRSS  in  terms  of  management, 
scheduling,  <->!<:. 

The  "Other  Payloads"  in  Table  5-9  have  sufficiently  low  data  rates  and/or 
sufficient  communications  delay,  that  addition  of  these  to  the  US  payload 
scenarios  would  have  minimal  impact. 
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Table  5-9 

Foreign  Payload  Communications  Drivers 


POLAR-ORBITING  PAYLOADS 


GROUP 

DUPLICATE 

DELAY 

PEAK 

AVG. 

(Mbps) 

(Mbps) 

CANADA 

Y 

COMM  4002  EARTH  RESOURCE  SENS. 

24  Hrs . 

300 

100 

Y 

TDMX  4000  RADARS 

24  Hrs. 

300 

100 

JAPAN 

Y 

E006  EARTH  OBSERVATION  FACILITY 

0 Hrs . 

300 

10 

EUROPE 

N 

E0B210  OPTICAL  INFRARED 

24  Hrs. 

300 

24 

Y 

E0B220  LAND  SAR  MULTIPURPOSE 

24  Hrs. 

300 

75 

Y 

E0B230  LAND  APPL.  SAR  AGR . 

- 

300 

38 

Y 

E0B300  OCEAN  SAR 

6 Hrs. 

300 

38 

OTHER  PAYLOADS  (PLATFORM  UNIDENTIFIED ) 

CANADA 

- 

SAAX4006 

24  Hrs. 

10 

1.5 

JAPAN 

- 

TOO 4 SPACE  ENERGY  EXP. 

24  Hrs. 

5 

00 

<N 

- 

S001 

24  Hrs. 

8 

8.0 

EUROPE 

- 

EOBXXX  LIDAR 

— 

150 

1.8 

- 

SCN060  ARTIC  COMM. 

0 Hrs. 

1.6 

1.6 

Table  5-10  lists  the  current  estimate  of  video  required  for  foreign  payloads 
(Avg.  10.4  Mbps).  It  is  not  known  whether  all  the  payloads  generating  this 
video  will  be  operational  during  the  same  years  or  whether  they  will  be  < I lie 
same  platform.  Again  the  foreign  payload  data  is  only  a first  cut  at  defining 
the  payload  requirements . 
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Table  5-10 

Foreign  Payload  Video 
(Reference  4;  Table  5-1) 


VIDEO 


EUROPE 

9.8 

Hrs/Day 

CANADA 

.5 

Hrs/Day 

JAPAN 

45.5 

Hrs/Day 

TOTAL 

58.8 

Hrs/Day 

Avg.  Video  @4.5  Mbps  10.4  Mbps 


In  summary,  the  primary  impact  of  foreign  payloads  on  communications  will 
potentially  result  from  POP  payloads  and  perhaps  payload  video.  However, 
because  of  the  uncertainty  regarding  foreign  payload  definition  they  will  not 
be  included  in  the  composite  analysis,  which  follows. 

5.4  Composite  Communications  Systems  Loading 

Composite  communications  loading  and  link  loading  is  developed  below  by 
examination  of  data  derived  thus  far. 

5.4.1  Internal  Distribution  System  Loading  for  the  Space  Station 

Table  5-11  and  5-12  indicate  the  communications  data  inputs  and  resulting 
composite  internal  distribution  systems  loading  for  the  IOC  and  growth  space 
station  scenarios,  respectively.  Distribution  of  information  in  all  digital 
format  on  the  Space  Station  has  been  assumed  primarily  to  simplify  analysis  of 
the  digital  downlink  loading  of  the  TDRSS.  Digital  distribution  channels  can 
easily  be  taken  out  of  the  potentially  several  digital  distribution  networks 
on  the  Space  Station  and  be  assigned  as  analog  on  analog  distribution 
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Table  5-11 

Strawman  Internal  Space  Station  Communications  at  IOC  During  Heavy  Loading 
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Cassette  source  (not  distributed) 
Includes  facilities/core  information 


Strawman  Growth  Internal  Space  Station  Communications  at  Heavy  Loading 
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I ! 

cm  cn 


Cassette  source  (Not  Distributed) 
Includes  Facilities/Core  Information 


networks.  An  objective  of  this  analysis  is  to  identify  boundary  conditions 
and  probable  loading  levels  of  the  communications  systems.  This  can  be  done 
for  both  the  digital  designs  and  analog  designs  by  identifying  data  rai  md 
channel  quantities. 

The  objective  of  the  data  analysis  in  Table  5-11  and  5-12  was  to  determine  a 
probable,  or  an  order  of  magnitude  type  determination  of  an  instant  in  i ime 
when  a heavy  instantaneous  communications  loading  would  be  placed  on  the  Space 
Station  communications  systems.  This  then  provides  an  estimate  of  the  upper 

bound  on  communication  capacity.  The  data  rates  used  for  each  line  of  the 
tables  were  taken  from  the  detailed  strawman  scenario  diagrams.  Table  5-4,  or 
from  the  statistics  presented  on  payloads..  The  column  labeled  "No.  of  Func . " 
lists  the  number  of  functions  that  would  occur  simultaneously  for  the 
composite  scenarios  developed  in  each  table.  In  the  case  of  EVA  there  are  two 
functions  (two  simultaneous  EVA  crewmen)  which  result  in  all  the  data  rates  in 
the  EVA  scenario  (from  Figure  2)  being  multiplied  by  2 and  listed  in  the 
appropriate  communications  service  column  (TV,  Voice,  etc.).  The  aclual 
distribution  of  functions  was  determined  for  both  Table  5-11  and  5-12  by 
attempting  to  involve  crew  members  in  as  many  communications— inter)  ive 
activities  as  appears  reasonable,  and  is  based  on  crew  work  schedules 
presented  in  References  1 and  6.  Although  the  simultaneous  involvement  of 
crewmen  in  the  selected  activities  presented  here  represents  a judgement  at 
this  point,  it  is  useful  to  bear  in  mind  that  the  primary  objective  wa^  lo 
establish  a heavy  loading  scenario  to  determine  an  upper  bound  on 
communications  loading. 

In  Table  5-11  the  attached  payload  video  and  data  rates  were  selected  from  the 
highest  loading  point  in  the  payload  data  profile  of  Figure  5-15.  The  cornu. .nd 
rate  was  taken  from  uplink  communications  in  Table  5-6.  Voice  interaction  for 
payloads  during  this  scenario  are  not  significant  because  none  of  the  crew  is 
available  to  interact  with  the  payloads.  It  is  however  recognized  that 
mission  specialists  may  require  audio  and  video  interaction  with  principle 
investigators  while  setting  up  an  experiment  and  at  other  times. 

After  summing  the  input  information  the  required  number  of  voice  and  ideo 
channels  are  listed  along  with  the  digital  audio/video  (123.028  Mbps)  and  the 
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SSDS  data  (34.951  Mbps).  Again,  these  rates  reflect  a created  model 
reflecting  a heavy  loading  scenario. 

In  the  growth  scenario  (Table  5-12)  the  input  data  rates  were  selected  in  a 
manner  similar  to  that  for  the  IOC  scenario  (Table  5-11).  As  in  the  IOC 
scenario,  no  OMV  or  OTV  activities  have  been  included  for  the  purpose  of  this 
analysis  because  crew  members  have  been  assigned  to  functions  with  more 
demanding  communications  requirements . For  other  scenarios  not  included  here 
crew  interaction  with  the  OMV  and  OTV  would  be  included.  The  interaction  with 

free  flyers  is  not  well  defined  for  the  space  station;  the  command  and  data 
rates  for  these  were  arbitrarily  assigned  a composite  average  of  1 Kbps  and 
3.5  Mbps,  respectively,  which  are  loosely  derived  from  the  Free  Flyer  scenario 
in  Figure  5-6.  The  composite  upper  bounds  reflected  in  this  growth  scenario 
resulted  in  a 175.476  Mpbs  audio/video  rate  and  a 108.234  Mbps  SSDS  rate. 

In  postulating  more  realistic  communications  scenarios,  it  is  useful  to 
consider  replacing  some  higher  payload  data  rates  with  average  rates  and 
reallocating  crew  activity.  This  is  particularly  true  when  one  recognises 
that  EVA  and  Orbiter  Docking  activities  are  not  daily  activities  and  the  crew 
would  likely  be  involved  in  some  of  the  attached  payload  functions  or  a sleep 
period.  This  has  been  done  in  Table  5—13  and  5—14  for  IOC  and  growth, 
respectively,  which  attempts  to  postulate  a more  "typical"  scenario.  The  data 
rates  for  attached  payloads  have  also  been  changed  to  the  average  data  rates 
for  payloads. 

The  composite  communications  loading  for  both  the  heavy  and  "typical" 
communications  loading  are  summarized  in  Table  5-15. 
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Table  5-13 

Strawman  Internal  Space  Station  Communications  at  IOC  During  "Typical"  Loading 
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Cassette  (not  distributed) 

Includes  facilities/core  information 


Table  5-14 

Strawman  Growth  Internal  Space  Station  Communications  During  "Typical"  Loading 
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l I 

CM 


Cassette  Source  (Not  Distributed) 
Includes  Facilities/Core  Information 


Table  5-15. 


Summary  of  Space  Station  Internal  Communications  Loading 


IOC 

HEAVY  LOADING  SCENARIO 

"TYPICAL"  LOADING  SCENARIO 

Table  No. 

9 

11 

Audio/Video 

123.0  Mbps 

56.2  Mbps 

SSDS 

35.0  Mbps 

27.4  Mbps 

Total 

158.0  Mbps 

83 . 6 Mbps 

GROWTH 

Table 

10 

12 

Audio/Video 

175.5  Mbps 

108.6  Mpbs 

SSDS 

108.2  Mbps 

56.2  Mbps 

Total 

283.7  Mpbs 

164.8  Mbps 

5.4.2 


The  internal  communication  load  includes  communications  which  is  for  intra 
space  station  purposes  as  well  as  communications  from/to  external  sources. 
Table  5-16  addresses  the  potential  TDRSS  downlink  (KSA)  communications  loads 
for  IOC  and  growth  depicting  upper  level  loading  and  hypothetical  "typical" 
scenarios.  Therefore  the  methodology  used  to  arrive  at  external  loading  was 
to  subtract  internal  communications  loading  that  did  not  require  transmission 
to  the  ground . 


Table  5-16.  Downlink  Loading  of  TDRSS 

HEAVY  LOADING  SCENARIO  "TYPICAL11  LOADING  SCENARIO 

IOC  119.8  Mbps  45.4  Mbps 

GROWTH  207.3  Mbps  88.4  Mbps 
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Only  10%  of  the  surveillance  video  will  be  transmitted  to  the  ground  (see 
Figure  5-8).  As  can  be  seen  in  Figure  5-10,  no  training  information  is 
transmitted  to  the  ground.  These  two  assumptions  are  based  on  our  development 
of  those  two  scenarios;  this  may  require  review  as  various  NASA  elements 
comment  on  the  model.  Video  for  PAO  (Public  Affairs  Office)  has  not  been 
specifically  identified  in  the  scenarios.  It  should  be  recognized  that  some 
PAO  video  includes  the  video  previously  addressed  and  that  other  PAO  video 
would  be  added  to  the  hypothesized  scenarios  during  special  occasions. 

5 • 4 • 3 SS  Uplink  Loading  of  TDRSS 

The  continuous  uplink  loading  of  TDRSS  is  minimal  as  indicated  in  Table  5-17. 
The  only  possible  heavy  loading  of  the  channel  would  result  from  Space  Station 
to  Ground  conversation,  video  conferencing,  transmission  of  training  video  or 
uplink  video  instruction  for  setting  up  payloads.  The  loading  from  these 
would  be  intermittent  and  for  the  most  part  could  be  scheduled  to  be 
appropriately  interleaved  with  any  unexpected  heavy  loading  of  the  uplink 
channel.  Special  uplink  loading,  such  as  program  loading  or  emergency 
information,  have  not  been  included  since  the  scenarios  pertaining  to  these 
situation  are  not  defined  at  this  time. 

Table  5-17.  Space  Station  Uplink  Loading  of  TDRSS 


IOC  GROWTH 


Attached  Payloads  (Table  5—6)  Avg . 
SS  Command/Control  (Table  5-4)  Avg. 
Crew  Member  Voice/Video 


101  Kbps  131  Kbps 

2 Kbps  4 Kbps 

Variable  Variable 


5 • 4 • 4 Communication  Link  Loading  for  EVA 

Two  crewmen  will  be  on  EVA  simultaneously  while  performing  activities  outside 
the  Space  Station.  The  communications  link  to  each  crewman  should  support 
loading  up  to  448  Kbps  and  22,064  Kbps  for  the  forward  and  return  links  (see 
Figure  5—3).  Lower  loading  levels  would  occur  depending  upon  the  audio, 
video,  telemetry  and  command  required  for  supporting  EVA. 
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5.4.5 


Orbiter  Communications  Link  Loading 


The  Space  Shuttle  Orbiter  (SSO)  has  a variety  of  communications  capabilities, 
many  of  which  may  not  be  required  for  communication  with  the  Space  Station. 
Further  analysis  of  the  communications  requirements  is  needed. 

Based  on  References  1 and  2,  communications  loading  between  a SSO  and  the 
Space  Station  should  require  a communications  capability  similar  to  that 
presented  in  Figure  5-4.  That  scenario  requires  two  voice  channels  (32  Kbps 
each)  and  some  telemetry/command  (2  Kbps)  on  the  communication  channel  to  the 
Space  Station.  Video,  audio,  and  command/telemetry  to  the  SSO  could  require  a 
composite  capacity  of  22,080  Kbps. 

It  should  be  noted  that  Reference  2 indicates  that  2 analog  TV  channels  (4.5 
MHz  each)  be  used  for  transmission  of  MRMS  video  to  the  SSO.  The  MRMS 
scenarios  in  Figure  5-7  assumed  4.5  Mbps  TV  for  distribution  on  the  Space 
Station.  This  is  not  intended  as  a recommendation  for  a digital  TV  link  to 
the  Orbiter;  rather,  it  is  a convenient  assumption  for  purposes  of  this 
traffic  analysis. 

5.4.6  Communications  Link  Loading  for  OTV /OMV 

Both  the  OTV  and  OMV  will  provide  similar  support  functions  with  the  primary 
difference  being  that  the  OTV  will  have  more  extensive  transportation 
capabilities.  Our  understanding  of  the  OMV  design  currently  under  study  by 
NASA  that  it  will  support  transmission  of  telemetry  and/or  video  at  a rate  of 
approximately  448  Kbps  and  reception  of  commands  at  a rate  of  approximately  64 
Kbps  (see  Figure  5-5).  The  average  rates  could  of  course  be  less,  depending 
on  the  OMV  activity  level.  The  use  of  this  video  rate  has  been  questioned  on 
several  occasions  because  it  may  not  be  sufficient  to  support  some  OMV 
activities,  such  as  robotic  repair,  maintenance,  and  docking.  A higher  22-25 
Mbps  video  rate  may  be  required-perhaps  even  on  two  channels  simultaneously. 

Until  the  design  of  the  OMV  is  better  defined  the  communications  loading  will 
be  uncertain.  The  communications  loading  for  the  OTV,  although  assumed 
similar  to  the  OMV,  is  even  less  certain  since  this  will  be  a growth  addition 
to  the  Space  Station. 
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5.4.7 


Free  Flyer  Communications  Link  Loading 


Free  Flyers  are  essentially  of  two  types: 

1.  Satellites  being  launched  and  serviced 

2.  Special  purpose  vehicles  that  may  operate  in  the  vicinity  of  the 
Space  Station. 

Until  specific  mission  requirements  can  be  defined  for  free  flyers, 
communications  loading  cannot  be  defined  except  for  the  link  capacities  (5  and 
25  Mbps  IOC  and  growth  as' identified  in  Reference  2). 

5 . 5 Recommendations  for  Further  Study 

5.5.1  The  baseline  and  assumptions  which  are  used  in  this  report  represent 
a viewpoint  which  is  based  on  the  "best"  information  available  to  use  at  this 
time.  This  includes  rates  and  guidelines  which  in  some  cases  were  derived 
from  explicit  NASA  sources;  in  other  cases,  were  arrived  at  via  indirect 
sources  or  engineering  judgement.  This  should  be  reviewed  as  new  information 
and  guidance  are  made  available. 


5.5.2  Areas  where  specific  further  investigation  is  suggested  are  discussed 
in  the  following  paragraphs. 

MI.DE.0 • example  of  the  factors  relating  to  the  relative  "softness"  of  the 
assumed  video  rates  and  mission  needs  is  described  below,  using  the  OMV  for 
reference  purposes:  the  OMV  requirements  document  does  not  identify  a 

specific  quality  of  video,  nor  an  attendant  rate.  However,  discussions  over 
the  past  year  with  contractors  on  the  Phase  B - OMV  study,  have  identified  the 
use  of  a relatively  low  (digital)  rate  for  TV  purposes,  i.e.,  448  KB/S. 
Further,  this  appears  to  be  a total  video  channel  allocation.  The  OMV 
requirements  document  asks  for  two  TV  cameras,  and  one  or  both  cameras  shall 
use  that  channel  separately  or  together.  This  rate  implies  a slow  scan  (e.g., 
5 frames/sec)  approach,  with  either  a compression  or  a "special  spot" 
algorithm,  and  probably  black-white. 
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Discussion  with  video  technology  personnel  at  NASA  have  indicated  that  they 
believe  a much  higher  resolution  video  requirement  exists  — probably  requiring 
the  equivalent  of  NTSC,  full  color;  this  implies  a video  rate  in  the  order  of 
22—25  MB/S,  depending  on  an  acceptable  compression  algorithm  (see  discussion 
in  5.3.1). 

These  differences  are  dramatic  enough  to  require  a revisit  of  the 
communications  profile,  since  they  impact  the  capacity,  power,  and  flexibility 
of  the  SSDS , as  analysis  of  video  standards  determines  that  rates  may  be 
increased . 

EXPERIMENTAL  PAYLOADS . The  information  used  for  representing  communications 
profile  for  the  US  payloads  was  derived  from  the  bloods  Hole  Mission  workshop 
outputs,  which  are  reasonably  complete  and  are  in  the  available  data  base. 
However,  the  information  related  to  foreign  payloads  is  much  less  complete  and 
also  appears  to  overlap  with  some  U.S.  experiments.  IOC-growth  transition 
schedule  information  in  minimal.  As  these  foreign  experiments  are  delineated 
in  greater  detail,  the  SSDS  system  requirements  may  require  modification. 

EI\ID-TO—  END  DELIVERY  DELAYS.  The  communications  profile  does  not  address 
end-to-end  delivery  of  data.  However,  as  traffic  builds,  the  delays  due  to 
service  queues,  buffer  delays,  and  routing  increase.  Therefore,  it  is 
suggested  that  this  area  be  investigated  with  particular  emphasis  on  queue 
delays;  transmission  delays  should  be  essentially  constant.  If  true  time 
transparency  could  be  guaranteed  (i.e.,  T^  specified  delay)  regardless  of 
traffic  conditions,  this  could  be  accomplished  by  faster  processing  and  buffer 
service  and/or  by  assigning  different  delivery  times  to  various  classes  of 
data. 

TDRSS  ACCESS.  The  total  TDRSS  channel  allocation  and  the  access  protocol  that 
is  used  obviously  drives  buffer  sizes  and  affects  delays.  Dynamic  schedule 
algorithms  should  be  investigated  in  order  to  reduce  the  effect  of 
contention/conflicts  as  well  as  for  mitigating  predictable  data  throttling 
periods.  These  would  give  some  insight  into  worst  case  delays  and  assist  in 
developing  buffer  use  and  sizing  options. 
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B|I_ERROR._RATE/DftTA  INTEGRITY , The  end-to-end  objectives  for  data  integrity 
(the  acceptable  BER)  may  not  be  the  same  for  the  three  categories  (data, 
video,  voice)  of  information;  they  may  even  vary  within  any  category.  Error 
detection  and  correction  codes  for  individual  links  in  an  end-end  connection 
affects  power,  processing  requirements , effective  link  efficiency,  etc.  The 
use  of  error  protective  codes  within  the  data,  within  a frame,  and/or  within  a 
packet  format  are  areas  which  requires  further  investigation. 

It  is  probably  worth  reiterating  that  video  and  audio  have  sufficient 
redundancy  (i.e.,  assuming  that  compression  algorithms  are  not  too  severe)  in 
terms  of  information  patterns  that  the  ability  of  human  senses  to  integrate 
across  relatively  short  errors  could  reduce  error  coding  requirements  to  those 
necessary  for  frame,  synch,  headers,  etc. 

It  is  also  useful  to  consider  adaptive  code  strategies  to  accommodate 
different  conditions;  e.g.,  in  periods  of  high  activity  but  good  quality 
links,  a reduced  code  may  be  acceptable,  while  in  periods  of  poor  quality  more 
robust  codes  may  be  required.  Also,  within  a constrained  environment,  as 
within  a LAN  on  the  Space  Station,  or  from  a TDRSS  ground  terminal  to  a 
terrestrial  network  interface  (e.g.,  COMSAT  terminal  to  a switched  network 
node)  error  detection  (ACK/NACK)  may  be  adequate  rather  than  a more  complex 
FEC  approach. 
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6.0  ONBOARD  SSDS  DEFINITION 


Section  6.0,  presents  the  definition  of  the  onboard  Space  Station  Data  System 
(SSDS)  and  the  onboard  Platform  (POP  and  COP)  Data  System.  The  Space  Station 
System  is  described  in  sections  6.1  to  6.8;  the  Platform  system  is  described 
in  section  6.9. 

6.1  Space  Station  Onboard  Introduction  and  Overview 

For  the  purposes  of  this  study,  the  onboard  SSDS  has  been  defined  to  include 
the  onboard  networks,  the  network  interface  units  (NIU's),  subsystem  data 
processors  (SDP's),  workstations  (MPACs),  mass  storage  units  and  the  software 
that  resides  in  or  supports  these  elements.  It  should  be  noted  that  the 
subsystem  application  software  is  included  in  this  definition.  The 
architecture  and  system  definition  described  herein  are  products  of  the  SSDS 
A/A  Study  approach  and  methodology  outlined  in  Section  2.0.  This  architecture 
definition  is  preliminary.  Some  elements  are  defined  in  more  detail  than 
others  to  explore  specific  design  or  technology  driver  aspects  of  the 
architecture.  The  prime  inputs  used  to  develop  this  preliminary  definition 
were : 


• Task  1 - Requirements  Definition 

• Task  2 - Options  Development 

• Task  3 - Trade  Studies 

• Space  Station  Phase  B RFP 

• Space  Station  Reference  Configuration 

• Team  Systems  Engineering  Practices 

• NASA  Guidance  and  Feedback 

• Langley  Mission  Data  Base  and  Woods  Hole  Data 

The  major  metrics  utilized  throughout  this  task  to  evaluate  architectural 
alternatives  and  influence  key  design  decisions  are  also  common  to  all 
supporting  analyses  (options  development,  trade  studies)  and  include  the 
following : 
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- Cost 

- Standard ization/Commonality 

- Technology  Insertion  and  Readiness 

- Performance 

- Growth  and  Flexibility 

- User  Acceptance 

The  primary  steps  of  the  onboard  system  definition  process  include: 

Partition/allocate  the  Task  1 Functional  Requirements  to  onboard 
subsystems,  physical  modules  and  computing  elements  for  traceability. 

- Describe  and  characterize  the  onboard  elements  including  rational. 

- Present  an  architecture  and  topology  rationale  that  connects  the 
distributed  elements. 

- Document  the  System  Definition  and  key  design  decisions  made  to  date. 

The  supporting  trade  study  results  and  options  development  were  major  inputs 
into  the  system  definition  process.  Recommendations  and  supporting  data  in 
the  following  trade  studies  and  related  options  categories  were  important 
influencing  factors  in  most  key  design  decisions: 

Network  Media  options 

- NIU  options 

Onboard  LAN  trade  study  and  options 

- Operating  System  trade  study  and  options 
Data  Base  Management  trade  study  and  options 

- Fault  tolerance  trade  study  and  options 
Time  management  options 

The  key  design  decisions  made  to  date  are  summarized  in  Table  6.1-1. 
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System  Definition  Decision  List 
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Reconf igurati on 
Secu ri ty 
Safe haven 
Handle  more  data 


Table  6.1-1  (continued) 
System  Definition  Decision  List 
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options  (serial, 
parallel) 

Bridges  (layers  1-3) 
PL  LAW  unique  is  open 
question 
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enhanced  system  flexibility 
Single  or  multiple 
SDP's  for  subsystems 
not  precluded 


6.2  Partitioning/Allocation  of  Functional  Requirements  into  Onboard  Subsystems 

This  section  describes  the  allocation  of  onboard  SSDS  functional  requirements 
to  subsystems.  Functions  were  previously  allocated  to  onboard  the  Space 
Station  as  a result  of  the  Autonomy/Automation  Trade  Study.  For  clarity,  the 
subsystem  allocation  process  is  accomplished  in  two  steps: 

• Functional  requirements  partitioned  into  the  reference  configuration 
defined  subsystems  as  a starting  point.  Some  restructuring  will  be 
described  in  subsequent  sections. 

• Subsystem  functional  requirements  allocated  to  resources  (SDPs,  Wills 
and  workstations). 

The  design  characteristics  (sizing  data)  of  allocated  SSDS  functions, 
functional  interface  connectivity,  discipline  orientation,  subsystem 
(functional)  autonomy  and  the  advantage  of  recognizable  subsystem  names  were 
major  factors  in  our  core  subsystem  definition. 

Table  6.2-1  presents  an  "application  subsystem"  overview  of  prototype  memory 
sizing  in  kilobytes  (Kbytes)  and  mean  processing  rates  in  kilo-operations  per 
second  (KOPS)  using  the  reference  configuration  subsystem  names.  A detailed 
breakout  of  each  of  the  subsystems  are  tabulated  in  Section  6.8.  The 
exception  is  "Propulsion"  which  we  assumed  contained  no  software  that  is 
resident  in  an  SDP.  The  IOC  and  Growth  subsystem  summations  represent  only 
the  application  code  and  data  sizing  and  computational  rates.  The  operating 
system  sizing  and  rates  are  added  later  when  SDP  memory  configurations  are 
presented  (total  software  load). 

The  application  memory  size  for  each  subsystem  is  conservative  from  the 
standpoint  that  it  represents  an  arithmetic  sum.  Not  all  elements  of  each 
subsystem  are  necessarily  main  memory  resident  in  an  SDP  at  all  times.  This 
also  naturally  applies  to  their  computational  rates. 
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Table  6.2-1 


TASK  1 FUNCTIONS  HAP  TO  REFERENCE  CONFIGURATION 


SUBSYSTEM 

SUMMARY  OATA 

MEAN 

DATA 

MEMORY  (KBYTES1 

PROCESSING  ( K0PS1 

1.  ELEC  PWR 
4. 2. 1.1-7 

IOC 

GROWTH 

IOC 

GROWTH 

443 

863 

76 

148 

2.  GN&C 

4.1,  2. 5. 3. 3,  2. 5. 4. 3 

878 

1181 

267 

379 

3.  THERMAL  CONTROL 
4. 2. 2. 1-4 

76 

131 

11 

16 

4.  ECLS 

4. 2. 4. 1-7 

117 

119 

17 

17 

5.  PROPULSION 

NO  SOFTWARE  — 

CONTROLLED  BY 

GN&C 

6.  STRUCTURES/MECHANISMS 
4. 2. 3. 1-5 

108 

252 

52 

106 

7.  CREW  SYSTEMS 

4.3.1,  4.3.3,  4.3.4 

210 

292 

50 

75 

8.  COMM  & TRACKING 

1.1. 1- 5,  1.2. 1-5, 

4. 2. 5. 1- 7,  2. 5. 3. 5, 
2. 5.4.6 

851 

1608 

622 

753 

9.  INFORMATION  & 

OATA  MGMT  SYSTEM 
2.1,  2.2,  2.3,  3.3,  3.4 
4.3.2,  4.3.5,  4.5, 
4.1.6,  5.1.1,  5.1.2 

2578 

4126 

45 

113 

0.  PL  & SERVICING 
ACCOMMODATIONS 

2.4,  2.5.1,  2.5.2,' 

2. 5. 3.1,  2. 5. 3. 2, 

2. 5.3.4,  2.5.4,  2.5.5, 
4.4 

2466 

3122 

26 

49 

A comparison  of  these  sizing  estimates  to  Shuttle  software  memory  requirements 
illustrates  the  magnitude  of  the  problem.  The  Shuttle  AP-101  onboard  computer 
application  software  total  code  and  data  size  is  approximately  400,000  32--b:i.t 
words  or  1600  Kbytes. The  results  of  the  comparison  is  shown  below. 
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Space  Station 

Current  Shuttle 

IOC 

Growth 

1600  Kbytes 

• 8127  Kbytes 

• 12,404  Kbytes 

(Application  Code) 

• 5.1  times  Shuttle 

• 7.8  times  shuttle 

For  reference,  the  current  Shuttle  AP-101  computer  capability  is  425  Kbytes 
and  450  KOPS,  The  upgraded  AP-101S  is  1081  Kbytes  and  approximately  1000  KOPS. 

The  IOC  KOPS  values  in  Table  6.2—1  are  well  within  the  capabilities  of  present 
space  qualified  processors  for  any  subsystem.  The  Growth  requirements 
indicate  the  need  for  newer  technology  (faster)  processors  in  the  Electrical 
Power  subsystem. 

6.3  Subsystems  Allocation  into  Architectural  Elements 

The  following  discussion  traces  the  onboard  function  allocations  into  SDP's. 
Later,  workstation  functionality  is  discussed  that  allows  down  loading  from 
SDP's,  (Section  6.4.6  and  6.6) 

Table  6.3-1  describes  the  onboard  subsystem  allocation  into  SDP  memory 
configurations.  A memory  configuration  is  defined  as  a collection  of  one  or 
more  sets  of  subsystem  application  software.  Most  of  the  subsystem  function 
groups  of  Table  6.2-1  are  retained  intact  with  respect  to  the  Reference 
Configuration  names.  The  most  notable  exception  is  that  the  Information  and 
Data  Management  has  been  partitioned  into  a DMS  Operational  Data  Base  (0D8) 
grouping  and  Facility  Management  (see  Table  6.3-2).  The  DMS  grouping 
represents  a generic  set  of  services  that  are  available  to  all  core  subsystems 
and  are  also  available  as  options  for  the  payload  community.  Tables  6.3-2  and 
6.8-1  (Section  6.8)  together,  provide  the  sizing  data  for  these  DMS  services. 
These  will  be  discussed  later.  The  remaining  DMS  items  (Tables  6. 2-1/6. 8-1) 
are  considered  as  standard  System  Services. 

The  Facility  Management  grouping  of  Table  6.3-2,  in  conjunction  with 
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Table  6.3-1 


SSOS  A/A  Core  and  Payload  Memory  Configurations 


No. 

Name/Function 

IOC 

Mem(1)/CPU(2) 

(KBYTES/KOPS) 

Growth 

MemO  )/CPll(2) 
(KBYTES/KOPS) 

1 . 

GN&C 

• NAV 

• Guidance 

• ATT  Cont 

• Traffic 

• Tracking 

• OMV  & OTV  Deploy/ 
Retrieve 

1038/307 

1341/436 

2. 

• Elec  Pwr 

• Thermal  Control 

• Communications 

1530/815 

2852/1055 

3. 

• ECLSS 

• Crew  Systems 

• Str  & Mech 

595/137 

913/228 

4. 

DMS  ODB 

1280/38 

2071/62 

5. 

Facility  Mgmt 

1618/14 

2555/68 

6. 

Payload  Processing 
(Function  2.5.1) 

360/1 

650/1 

7. 

Payload  Processing 
(Function  2.5.1) 

360/1 

650/1 

8. 

Payload  and  Servicing 
Accommodations 

2626/30 

3372/57 

(1)  Application  size  from  Tables  6.2- 
(+250  KBYTES  for  growth). 

-1/6. 8-1  +160  KBYTES 

for  operating  system 

(2)  KOPS  from  Tables  6. 2-1/6. 8-1  + 15%  of  total  application  KOPS  for 
operating  system  overhead. 
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Table  6.8-1,  describe  functions  which  are  collected  together  as  a required 
central  service  for  the  Space  Station.  The  functions  are  global  in  nature  and 
allow  central  status  monitoring  and  command  control  for  both  the  core  and 
payload  systems. 

The  remaining  subsystem  sizes  were  significantly  smaller  than  the  IDMS.  The 
memory  configurations  of  Table  6.3-1  were  derived  by  the  following  rules: 

• Retain  well  recognized  function  group  names  (discipline  oriented) 

• Reasonable  balance  of  memory  and  throughput  loads  (minimize 
power/ thermal  resources  required  by  onboard  SSDS) 

• Grouping  of  functions  that  may  be  required  for  one  or  more  physical 
modules  (e.g.,  power,  thermal  and  communication  and  ECLSS,  crew 
systems  and  structure/mechanism. ) 

• Separation  of  functions  (as  much  as  possible)  between  those 
identified  with  core  operations  and  payload  operations. 

• Minimize  network  interaction 

• Growth  of  memory  configurations 

The  Communications  and  Tracking  Subsystem  of  the  reference  configuration  was 
restructured  to  include  only  the  communications  related  functions  (under 
function  4.2.5).  The  tracking  function  of  pointing  all  steerable  hardware 
(solar  arrays,  antennas,  payload  pallets,  and  movable  mounts)  were  allocated 
to  a tracking  Subsystem.  The  hardware  associated  with  sensing  and 
self-locking  on  radiated  signals  is  associated  with  the  Communications 
Subsystem. 

Appendix  C defines  all  SSDS  external  interfaces  including  the  SSDS  to 
subsystem  sensors/eff ectors  derived  from  the  Task  1 developed  functional 
requirements  data  base.  Table  6.3-3  provides  cross-correlation  of  the  Task  1 
defined  externals  (abbreviated)  to  the  sensor/effector  terminology  used  in 
this  system  definition  report. 
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Table  6.3-2 

PARTITIONING  OF  IDHS  FUNCTION  SET* 


DMS  ODB 

FACILITY  MANAGEMENT 

4.1.6 

TIME  8.  FREQUENCY  MGMT. 

2.1 

VALIDATE  PL  CMMD 

5.1.1 

FIGHT  DATA  BASE  MGMT. 

2.2 

CHECK  PL  CMMO  RESTRICTION/ 

5.1.2 

FLIGHT  RESOURCE  MGMT. 

CONSTRAINTS 

5.1.3 

DISPLAYS  & CONTROLS 

2.3 

VALIDATE  CORE  CMMO/DATA 

3.3 

DEVELOP  OPS  EVENT  SCHEDULER 

3.4 

SEQUENCE  OPS 

4.3.2 

SPACE  STATION  SAFETY 

4.3.5 

OPS  AND  PROCEDURE  SUPPORT 

4.5 

MONITOR  & STATUS  SYSTEM 

*S1z1ng  data  for  these  functions  appears  in  Table  6.8-1  (Section  6.8) 

The  data  of  Table  6.3—1  were  used  to  select  the  size  of  the  SOP.  To  cover 
growth  and  provide  an  adequate  margin,  an  SDP  size  of  4 megabytes  and  2 MIPS 
is  recommended.  Large  elements  of  Payload  and  Servicing  Accommodations  (P&SA) 
are  candidates  to  be  either  loaded  into  an  SDP  or  a workstation  for  execution 
because  of  their  infrequent  use.  For  example.  Function  2.6  SSPE  Checkout  and 
Service  (Table  6.8—1)  is  1100  Kbytes.  If  this  is  saved  in  secondary  mass 
storage,  the  P&SA  SDP  memory  configuration  can  be  reduced  by  1100  Kbytes. 
Therefore,  the  largest  SDP  memory  configuration  in  Table  6.3-1  then  becomes 
No.  2 (Elec.  Power,  Thermal  and  Comm)  at  3408  Kbytes  (growth).  This  leaves  an 
additional  margin  of  more  than  33%  beyond  the  estimated  growth  size.  This 
technique  can  be  applied  to  the  other  memory  configurations  as  well. 

The  sizing  estimates  do  not  include  any  consideration  of  extensive  AI 
processing.  The  data  in  our  Function  Data  Base  for  the  onboard  functions 
generally  represents  traditional  sizing  methods.  A policy  that  augments  these 
base  numbers  for  AI  needs,  when  they  become  defined,  should  be  addressed. 
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TABLE  6.3-3  (Page  1 of  3) 

ONBOARD  ARCHITECTURE  CONFIGURATION  SENSORS  & EFFECTORS 
MAP  TO  APPENDIX  C EXTERNAL  INTERFACES 


SENSORS 
& EFFECTORS 


ABBREVIATION* 

DEFINITION 

APPENDIX  ABBREVIATIONS 

Align 

Structural  Alignment 

ALIGN  S 

Sensors  and  Controller 

MOOESENS 

«,  B ACT 

Solar  Array  Gimbal 

PNTG  MNT 

Control  Actuators 

CMG 

Control  Moment  Gyros 

CMG 

Comm  I/F 

Communication  Gateway 

COMEQUIP 

OMVOTVIF 

COMM  I/F 

COMMSYS 

CONSTI/F 

OMV  I/F 
OTV  I/F 

Crew  Sys 

Crew  Systems 

EMU 

MMU 

PHYS  MON 

WASTE  AN 

ECLSS 

Environmental  Control  and 

PRESCOMP 

TEMP/HUM 

Life  Support  System 

AIR  TEMP 

POT  SUPL 

AIR  TOX 

CABNPRES 

AIRCIRC 

CONTAMSR 

AIRMAKUP 

ECLSS 

ATM  CTL 

FIRE  CTL 

GREYWATR 

FIREOECT 

HUMIOITY 

OX  LEVEL 

♦See  Figures  6.6-1  and  6.6-2 
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TABLE  6.3-3  (Page  2 of  3) 

ONBOARD  ARCHITECTURE  CONFIGURATION  SENSORS  & EFFECTORS 


MAP  TO  APPENDIX  C EXTERNAL  INTERFACES 

SENSORS 
& EFFECTORS 
ABBREVIATION* 

DEFINITION 

APPENDIX  C ABBREVIATIONS 

GPS 

Global  Positioning  System 

GPS  TRAK 

MAG  Torq 

Magnetic  Torquer 

MAGTORQ 

Mech 

Mechanical  Latches,  Connectors 

AIRLKCTL 

AIRLOCK 

MECH 

STR  MECH 

MRMS 

Mobile  Remote  Manipulator  System 

MRMS 

MTU 

Master  Timing  Unit 

TIMEFREQ 

PL's 

PL  Mount 

Payloads  and  Pallets 

PALLET 
P/LCONST 
P/LCSTIF 
POP/COP 
SS  P/L 

Prox  Ops 

Proximity  Operations 

TRAKSENS 

PORT 

PROXTRAK 

*See  Figures 

6.6-1  and  6.6-2 
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TABLE  6.3-3  (Page  3 of  3) 

ONBOARD  ARCHITECTURE  CONFIGURATION  SENSORS  & EFFECTORS 
MAP  TO  APPENDIX  C EXTERNAL  INTERFACES 


SENSORS 
& EFFECTORS 


ABBREVIATION 

DEFINITION 

APPENDIX  C ABBREVIATIONS 

Pwr 

Power  System 

CHRG/REG 
ENERGYST 
PWR  SYST 

PWRSWTCH 

SLRARRAY 

SWITCHGR 

RAD  Cont 

Radiator  Control 

PNTG  MNT 
RADIATOR 

RCS 

Reaction  Control  System 

RCS 

Star  Tracker 

Star  Tracker 

STARTRAK 

Strap  Down 

Strap  Down  Gyro  or  Inertial 
Measurement  Device 

RATEGYRO 

THM 

Thermal  Control  System 

THERMCAP 
COOL  CTL 

THERMCTL 

HTEMPCTL 

FL  LOOPS 
FLUIDCTL 

LTEMPCTL 
P/L  IFHX 
RADIATOR 

Trk 

Long  Range  Trackers 

L/R  TRAK 
TRAKSENS 

*See  Figures  6.6-1  and  6.6-2 
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6.4  Architecture 


6.4.1  Overall  Partitioning 

The  overall  onboard  architecture  presented  here  has  most  of  the  same 
connectivity  generalized  in  the  NASA  Reference  Configuration.  However,  the 
system  definition  process  of  this  study  has  resulted  in  a more  specific  and 
detailed  configuration.  An  overview  of  the  significant  architectural  features 
and  a comparison  with  the  Reference  Configuration  is  provided  in  Table  6.4-1. 

6.4.2  Network  Configuration 

The  onboard  local  area  network  (LAN)  provides  the  means  for  information 
transfer  between  communicating  Onboard  SSDS  elements.  Local  area  networks 
basically  consist  of  transmission  media,  Network  Interface  Units  (NIUs),  and 
the  Network  Operating  System  (NOS)  (Figure  6.4—1  shows  a generic 
representat ion  of  a LAN).  The  NOS  is  discussed  in  more  detail  in  Sections 

6 . 4 . 2 . 2 and  6.4.4. 

1 he  Space  Station  onboard  LAN  must  accommodate  requirements  for  high 
performance,  reliability,  maintainability,  and  evolutionary  growth,  in  a 
cost-effective  manner.  This  results  in  a design  that  must  provide  features 
such  as  high  network  bandwidth,  fault  tolerance  capabilities,  modularity  and 
the  appropriate  application  of  standards  to  allow  design  extendability  and  to 
incorporate  new  technology. 

6.4.2. 1 LAN  Definition 

In  defining  the  Space  Station  onboard  LAN,  the  configuration,  level  of 
standardization,  transmission  media,  topology  and  media  access  method,  as  well 
as  the  functions  performed  by  the  network  communication  system  must  be 
addressed . 
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X 


TABLE  6.4-1 


REFERENCE 

CONFIGURATION  SSDS  A/A 

TWO  LAN  NETWORKS  SAME 

- CORE 
PAYLOAD 


SINGLE  COMM  SAME 

GATEWAY  TO  TORS 
AND  CONSTELLATION 


PAYLOAD  AND  CORE  LAN  SAME 

GATEWAY  TO  COMM  NODE 


t BACK-END  SOP  I/Fs  TO 
SENSORS  AND  EFFECTORS 
t NIU  I/Fs  TO  SENSORS 
AND  EFFECTORS 

# SINGLE  I/F  BETWEEN  NIU  AND  SDP 


• NO  BACK-END  I/F  TO  SDP 

• SAME 

• SAME 


# GN&C  SET  OF  SDP ' s SEPARATED 
FROM  IDMS  SDP  SET 

• GN&C  SPLIT  INTO  TWO  MEMORY 
CONFIGURATIONS  (NAV/TRAFFIC,  G/C) 


SIMILAR  - - ASSIGNED  SDP 
TRIAD  WITH  BACKUP 
FLEXIBILITY 

GN&C  PRELIMINARY  SIZING 
DOES  NOT  ORIVE  SDP 
SIZING  (NO  GN&C  FUNCTION 
SPLIT) 


DEDICATED  SDP(s)  TO  SUBSYSTEMS  COMBINE  SMALLER  SUBSYSTEMS 

(H/W  INTENSIVE)  INTO  SINGLE  GPC(s) 

(SOFTWARE  PARTITIONING) 
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6. 4. 2. 2  Configuration 


Onboard  the  Space  Station  there  are  two  alternatives  for  configuring  the 
network  communications:  1)  one  LAN  interconnecting  all  devices  and 

2)  multiple  LANs  interconnected  by  bridges/gateways.  The  multiple  LAN  option 
was  determined  to  be  the  most  suitable  configuration  onboard  the  Space  Station 
per  the  Onboard  LAN  Trade  Study  (Task  3),  This  configuration  provides  a 
highly  reconf igurable  system  which  would  potentially  handle  more  data  with 
minimum  resource  contention.  It  not  only  allows  for  an  easier  build-up 
(integration,  test,  verification)  with  one  or  more  LANs  per  module,  but  also 
enhances  security/privacy  since  the  payload  and  core  devices  would  be  on 
physically  different  LANs. 

6. 4. 2. 3  Level  of  Standardization 

The  multiple  LANs  should  all  conform  to  the  same  standard  at  IOC,  but  this 
does  not  preclude  the  use  of  multiple  standards  for  LANs  in  the  growth  phase. 
The  single  standard  for  LANs  at  IOC  allows  for  a simple  bridge  with  no  need 
for  gateways  while  also  satisfying  the  commonality  requirement.  Having  a 
single  standard  for  LANs  at  IOC  provides  the  most  cost-effective  solution. 
Simulation  analyses  has  shown  that  there  would  be  relatively  little 
performance  gain  to  warrant  matching  LAN  Topology  and  access  methods  to 
variations  in  module  network  traffic  characteristics  (i.e.  frequency 
distribution,  mean  packet  sizes,  etc.). 

However,  since  future  requirements  and  technology  developments  may  vary, 
multiple  LAN  standards  after  IOC  should  be  allowed.  This  is  consistent  with 
the  Onboard  LAN  Trade  Study  (Task  3). 


6. 4. 2. 4  Transmission  Media 

The  transmission  media  for  the  primary  LANs  onboard  the  Space  Station  should 
be  optical  fiber.  This  media  has  a high  bandwidth  allowing  it  to  support  high 
rate  applications  such  as  payloads,  and  also  provide  a high  growth  potential. 
It  is  also  highly  secure  and  has  a high  noise  immunity,  low  weight,  and  an 
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extremely  low  Bit  Error  Rate  (BER).  Optical  fiber  can  be  used  for  inside  the 
modules  and  outside.  Outside  the  modules,  fiber  can  be  placed  along  the 
structure  to  allow  for  the  connection  of  payloads  and  core  devices  located  on 
the  structure  to  the  LAN;  however  these  fibers  may  require  additional 
shielding  for  large  temperature  variations  and  radiation. 

Between  the  NIU's  and  back-end  devices  and  between  the  SDP's  and  NIU's 
(sensor/effectors,  workstations,  payloads),  high  bandwidth  fiber  optics  are 
not  required.  Therefore,  twisted  shielded  pair  can  normally  be  used  for 
serial  and  parallel  transmissions.  This  media  is  low  cost,  highly  reliable 
and  can  operate  above  1 Mbps  which  will  satisfy  most  back-end  rate  user  needs. 

Specific  high  rate  payloads  require  data  rates  that  currently  exceed  the 
computational  and  input/output  capabilities  of  todays  NIU's  and  SDP's.  These 
cases  require  dedicated  media  3uch  as  coax  or  fiber  to  move  their  data 
directly  to  the  onboard  C&T  interface  to  be  multiplexed  with  lower  rate  data 
and  transmitted  to  a ground  receiving  station(s). 

6. 4. 2. 5 Topology  and  Media  Access  Method 

The  topology  and  media  access  method  selected  for  the  LANs  is  token  passing 
rings  (e.g.,  ANSI  X3T9.5,  FDDI  system)  with  redundancy  paths.  The  cost  and 
risk  associated  with  the  ANSI  X3T9.5  FDDI  should  be  relatively  low  since  this 
is  an  emerging  standard.  Since  this  system  is  not  currently  available,  the 
cost,  physical  characteristics , and  environmental  characteristics  have  not  yet 
been  determined  and,  therefore,  could  not  be  evaluated.  It  is  felt,  however, 
that  these  characteristics , once  defined,  will  satisfy  the  Space  Station 
requirements . 

6. 4. 2. 6 Network  Communications  Functions 

The  functions  performed  by  a network  communications  system  will  be  described 
in  terms  of  the  International  Standards  Organization  Open  Systems  Interconnect 
(ISO/OSI)  model  for  layered  communications  systems.  The  layered  architecture 
provides  flexibility  in  revising  and  augmenting  the  system.  The  possible  set 
of  functions  performed  by  each  of  the  seven  ISO/OSI  layers  are  shown  in  Table 
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6.4—2.  The  ISO/OSI  model  allows  for  the  absence  of  some  of  the  functions  or 
layers  if  they  are  not  required  for  a given  communications  system.  As  the 
need  arises,  however,  these  functions  or  layers  may  be  added  with  minimal 
impact  to  the  existing  system. 

In  order  to  provide  a high  performance,  cost  effective  system  for  the  onboard 
LAN,  only  the  required  software  services  should  be  provided  at  IOC.  However, 
the  hardware  must  be  sized  at  IOC  to  allow  for  additional  software  services  to 
be  incorporated  for  planned  growth. 

One  significant  question  regarding  performance  addresses  the  issue  of  whether 
message  transfers  should  be  connection-oriented  or  connectionless  or  both.  A 
secondary  part  of  the  question  is  what  ISO/OSI  model  layers  should  support 
connection  oriented  transactions  if  they  are  required.  Connection-oriented 
service  at  the  Data  Link  layer  (layer  2)  implies  sequencing  and  error 
control.  However,  due  to  the  robust  nature  and  low  bit  error  rate  of  the 
transmission  medium,  these  services  can  be  performed  at  a higher  layer  (layer 
4)  and  still  provide  efficient  yet  reliable  communications.  The  Data  Link 
Layer  will  therefore  provide  connectionless  service. 

Connection  oriented  service  at  the  network  layer  allows  large  networks  (such 
as  multiple  LANs  interconnected  by  bridges)  to  be  operated  as  one  large 
network  with  deterministic  global  resource  allocation.  When  routed,  each 
packet  of  a message  follows  the  same  path.  Each  packet  transmitted  through  a 
connectionless  network  layer  is  routed  independently.  For  the  onboard  LAN, 
connectionless  service  at  the  network  layer  will  provide  efficient  services 
with  less  overhead. 

At  the  transport  layer,  connection  oriented  service  implies  end-to-end  flow 
control,  sequencing,  and  error  checking.  Since  these  essential  services  are 
not  provided  by  the  connectionless  network  and  data  link  layers,  the  transport 
layer  should  be  connection-oriented.  Of  the  ISO  Transport  Layer  classes  of 
service.  Class  4 will  provide  timely  and  reliable  data  transfer  for  mission 
critical  data.  The  functions  available  with  Class  4 include  data  transfer 
with  segmenting,  multiplexing,  error  detection  and  recovery,  flow  control,  and 
expedited  data  transfer.  Class  2 service,  which  provides  for  data  transfer 
with  flow  control,  may  be  satisfactory  for  sensors  with  over-sampled  or 
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Table  6.4-2:  ISO/OSI  Functions  (Part  1 of  2) 


I ISO/OSI  1 

FUNCTIONS 

IOC  | 

GROWTH 

1 

1 layer  j 

1 L 

1 

1 

1 

1 

1 1 1 1 1 

i 7 1 

Connection  Oriented 

x 1 

( 

1 1 

-bulk  file  transfer 

x ! 

1 

(application  | 

-virtual  terminal  usage 

x ! 

1 

-message  handling  services 

x I 

1 

1 1 

-job  transfer  and  manipulation 

x I 

1 

1 1 

1 | 

-stream  oriented  access  to  devices 

x 1 

i 

1 

1 1 
1 1 

Connectionless  Oriented 

x 1 

1 

1 

1 1 

-data  collection 

x j 

1 

1 1 

-outward  data  dissemination 

x 1 

1 

1 1 

-broadcast  / multicast 

x 

1 

1 1 
1 1 

-request  / response  applications 

x I 

1 

1 1 
1 1 

Connection  / Connectionless  Services 

1 

x 1 

1 

1 

1 1 

-10  of  communicating  partners 

x I 

1 

1 1 

-Establishment  of  authority  comm. 

x 1 

1 

1 1 

-Authorization  of  Intended  partn. 

x 1 

1 

1 1 

1 L 

-Application  Layer  Management 

X 1 
1 

1 

1 

1 1 
1 6 1 

-security  - encryption 

1 

1 

X 

1 

1 

1 1 

-data  compression 

source 

X 

1 

(presentation  | 

-character  code  conversion 

1 

X 

1 

1 1 

-graphics  syntax  conversion  I 

1 

X 

1 

1 1 

1 L 

-presentation  layer  management  | 

1 

I 

X 

1 

1 

1 1 

1 5 | 

1 1 

1 

-expedited  delivery  | 

-multiplexing  sessions 

1 

x 1 
1 

X 

1 

1 

1 

1 session  | 

-resynchronization  (checkpointing) 

x 1 

1 

-dialog  control 

X 1 

1 

1 1 
1 1 

-binding 

-quarantine  service 

x I 
1 

X 

1 

1 

1 1 

1 1 

1 L 

-sequencing  | 

-session  layer  management  j 

1 

x 1 

1 

X 

1 

1 

perishable  data.  It  is  recommended  that  at  least  two  classes  of  service  be 
offered  at  this  layer. 

The  transport  layer  connections  for  NOS-to-NOS  messages  should  be  established 
when  an  NIU  is  initialized  with  all  other  NIUs  on  the  LAN.  These  connections 
are  to  remain  in  effect  as  long  as  the  NIL)  is  operational.  Other  connections 
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Table  6.4-2:  ISO/OSI  Functions  (Part  2 of  2) 


1 

ISO/OSI | 

FUNCTIONS 

IOC 

GROWTH 

1 

l_. 

layer  | 

L 

1 

1 

1 

1 

1 

1 

J 1 1 1 1 

1 

4 1 

-connectionless  management  | 

X j 

1 

1 

1 

-connection  management  j 

x 1 

1 

1 

transport  | 

-segmentation  / reassembly  | 

x 1 

1 

1 

1 

-sequencing  j 

x 1 

1 

1 

1 

-blocking  / deblocking  | 

x 1 

1 

1 

1 

1 

1 

-header  error  control  j 

1 

x 1 

1 

1 

1 

1 

1 

1 

-data  multiplexing  connections  | 

x 1 

1 

1 

1 

1 

-expedited  delivery  j 

x 1 

1 

1 

1 

-resetting  j 

x I 

1 

1 

1 

-flow  control  j 

x 

1 

1 

1 

-error  detection  / control  1 

x 

1 

1 

1 

-address  mapping  j 

x j 

1 

1 

1 

-service  type  conversion  j 

x 

1 

1 

1_ 

1 

L 

-transport  layer  management  | 

1 

X 1 
1 

1 

1 

1 

1 

1 

3 1 

-routing  / switching  / relaying) 

1 

X 1 

I 

1 

1 

1 

-congestion  control  | 

x i 

1 

1 

1 

network  | 

1 

-packetization  /reassembly  j 

-sequencing  j 

X 1 
1 

X 

1 

1 

1 

1 

1 

1 

-header  error  control  j 

-quality  of  service  maintenance! 

x 1 
1 

X 

1 

1 

1 

1 

1 

1 

-expedited  delivery  | 

-error  control  j 

x 1 
1 

X 

1 

1 

1 

1 

JL_ 

1 

1 

1 

-accounting  (financial)  j 

-network  layer  management  j 

1 

1 

X 1 
1 

X 

1 

1 

1 

1 

1 

1 

1 

2 1 
1 

1 

-framing  | 

-error  control  / notification  j 

1 

x 1 

X 

1 

1 

1 

1 

data  | 

-media  access  j 

x I 

1 

1 

link  | 

-sequencing  j 

1 

X 

1 

1 

1 

J_ 

1 

1 

L 

-flow  control  j 

-data  link  layer  management  j 

1 

x 1 
1 

X 

1 

1 

1 

1 

1 

i_ 

1 

1 | 
L 

determined  by  medium  | 

1 

x I 

1 

1 

1 

are  established  by  tasks  and  are  disconnected  when  the  task  terminates.  A 
connection-oriented  transport  layer  provides  the  essential  error  control  and 
sequencing  and  also  provides  a higher  throughput  by  allowing  a connectionless 
network  and  data  link  layer. 
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The  session,  presentation  and  application  layers  should  offer  both 
connection— oriented  and  connectionless  service.  The  type  of  service  requested 
at  these  layers  should  be  the  same  in  all  three  layers.  Connections  at  these 
layers  should  be  established  for  each  process— to-process  communication  and 
should  have  a limited  lifetime. 

The  functions  provided  at  IOC,  should  be  those  which  support  connectionless 
network  and  data  link  layers  and  a connection— oriented  transport  layer.  The 
higher  layers  (application,  presentation  and  session)  support  both 
connection-oriented  and  connectionless  service.  These  functions,  which  are 
necessary  to  support  a reliable  data  transfer  service,  are  categorized  in 
Table  6.4—2  as  being  present  at  IOC.  Other  functions  can  be  added  as  needed 
beyond  IOC.  These  are  categorized  in  Table  6.4-2  as  possible  growth  items. 


In  the  presentation  layer,  the  syntax  negotiations  should  not  be  necessary  at 
IOC  since  common  elements  (hardware  and  software)  will  be  utilized  wherever 
possible.  As  shown  in  the  table  this  results  in  a null  presention  layer  for 
IOC.  Data  compression  and  encryption  services  can  also  be  employed  by 
customer/subsystems  requiring  such  services,  but  this  will  not  be  provided  by 
the  data  management  system  as  a standard  service  at  IOC.  However,  these 
services  could  be  provided  for  growth. 

The  application  layer  functions  serve  both  connection-oriented  and 
connectionless  types  of  data  transfers  as  shown  in  Table  6.4-2. 

6.4.3  NIU  Functional  Description 

As  determined  by  the  Onboard  Local  Area  Network  Trade  Study  (Task  3),  the  NIU 
should  perform  the  functions  corresponding  to  the  physical,  data  link, 
network,  and  transport  layers  of  the  ISO/OSI.  The  functions  corresponding  to 
the  session,  presentation,  and  application  layers  of  the  ISO/OSI  model  should 
reside  in  the  host  device.  The  division  of  layers  between  the  host  and  NIU 
are  possible  because  the  sess ion-transport  interface  allows  for  transparency 
with  minimal  impact  on  NIU  performance.  The  NIU  software  can  be  standardized 
since  only  common  communications  services  are  provided  by  the  NIU.  This 
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configuration  of  the  I\I1U  is  also  functional  as  a bridge/gateway  as  it  provides 
for  buffering  and  flow  control  in  the  NIU. 

When  sensors  and  effectors  are  attached  to  the  back-end  of  an  NIU,  these  NIU's 
only  provide  a subset  of  the  software  services  discussed  above.  For  example, 
only  the  Class  2 transport  layer  functions  may  be  provided. 

6.4.4  Operating  System/Application 

The  onboard  distributed  operating  system  (DOS)  will  provide  the  environment 
enabling  customers,  operators,  and  application  processes  to  share  the 
capabilities  of  the  resources  connected  through  the  Space  Station  local  area 
network.  The  "transparency " of  the  network  will  be  achieved  through  a highly 
reliable  and  flexible  interprocess  communication  facility  and  layered 
communication  protocol.  In  addition  to  the  DOS,  each  NIU  and  SDP  will  run  its 
own  traditional  operating  system  to  handle  such  tasks  as  interrupt  handling, 
task  management,  etc. 

The  DOS  will  be  physically  divided  between  network  interface  units  (NIUs),  and 
Subsystem  Data  Processors  (SDPs)  in  the  network.  Functions  which  execute  in 
every  NIU  or  every  SDP  may  be  thought  of  as  the  actual  operating  system  (OS) 
component.  The  remaining  functions  to  be  performed  by  the  DOS  will  reside  in 
certain  SDPs  and  may  be  thought  of  as  application  components  of  the  DOS,  This 
section  will  describe  functions  which  may  be  considered  as  responsibilities  of 
the  DOS,  Figure  6.4-2  illustrates  the  division  of  the  DOS  between  the  NIU  and 
SDP,  and  distinguishes  those  as  functions  which  form  the  OS  component,  and 
those  which  comprise  the  application  component.  Further,  the  division  of  the 
OS  component  between  NIUs  and  SDPs  will  also  be  discussed. 


6.4.4. 1 Generic  DOS  Functions 

The  list  below  is  a summary  of  the  wide  range  of  functions  provided  by  the 
DOS.  Another  important  component  of  the  DOS,  the  layered  protocol  used  for 
communiation  across  the  network  (which  is  also  split  between  the  NIU  and  SDP), 
has  been  described  in  context  with  the  discussion  of  local  area  networks  and 
network  interface  units  (6.4.2,  6.4.3). 
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1.  The  management  of  peripheral  resources  such  as  output  devices  and 
file  systems. 

2.  The  reconf iguration  of  memory  loads  when  necessary.  DOS  will  provide  for 
automated  switching  to  a cold  backup  and  automated  loading  of  spare 
computers  in  the  event  of  primary  failure.  If  fixed  memory  configurations 
are  utilized,  it  may  be  possible  to  employ  an  expert  system  or  some  other 
technique  to  automatically  replace  lower  priority  functions  with  higher 
priority  functions  when  all  processors  are  being  utilized. 

3.  An  efficient  interprocess  communication  facility  (IPC)  to  obtain  data 
or  to  initiate  an  interactive  session  with  another  process.  The 
syntax  and  semantics  of  this  facility  should  make  it  applicable  for 
communication  between  processes  on  a single  machine  or  ones  on 
different  machines. 

4.  A method  of  delivering  frequently  requested  data.  A method  other 
than  IPC  will  be  utilized  to  avoid  disturbing  the  owner  of  the  data 
and  for  potentially  faster  response  times.  The  results  of  the  DOS 


NIU  Hardware 
NIU  Software 


SDP  Hardware 
SDP  Software 


Figure  6.4-2.  DOS  Division  NIU  and  a SDP 
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trade  study  suggest  that  any  of  the  following  techniques  may  be 
utilized: 

• The  owner  of  the  data  sends  the  values  to  a database,  from  which 
the  values  may  be  obtained  by  applications. 

• The  owner  of  the  data  multicasts  the  values. 

• The  owner  of  the  data  broadcasts  the  values.  The  content  of  the 
broadcast  will  be  indicated  in  a special  field  in  the  layer  2 
header  so  that  every  NIU  is  not  forced  to  read  in  the  packet  in 
order  to  determine  its  contents.  This  scheme  is  the  most 
questionable  of  the  three. 

Monitoring  the  network  for  performance,  trending,  and  errors. 

Network  reconfiguration  — This  includes  initializing  and  shutting 
down  NIUs/SDPs  and  keeping  a record  of  where  checkpoint  information 
may  be  obtained  for  each  SDP.  Such  a record  will  be  utilized  in 
reinitializing  functions  of  that  SDP  in  a cold  backup.  Switching  to 
hot  backups  will  be  application  dependent. 

Scheduling  commands  and  functions.  The  need  for  scheduling  often 
arises  in  accessing  network  resources.  Such  scheduling  may  be  based 
on  classification  as  emergency,  real  time,  non-real  time,  background, 
etc . 

Verification  of  commands  - determination  of  whether  a command  is 
restricted/constrained  (i.e.,  potentially  hazardous  to  Station  or 
crew,  or  may  interfere  with  other  SS  or  payload  operations)  or 
unrestricted/unconstrained . 

The  implementation  of  individual  functions  associated  with  network 
communication,  including  addressing,  routing,  congestion  control,  and 
flow  control. 
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6. 4. 4. 2 The  Application  Component  of  the  DOS 

Several  of  the  functions  listed  above  need  not  be  performed  in  every  l\IIU  or 
every  SDP.  Still  others  require  a sufficient  amount  of  available  CPU  and 
memory  resources  such  that  it  is  not  feasible  to  perform  the  function  in  every 
NIU  or  every  SDP  (e.g.,  such  a function  is  a name  server  for  determining 
physical  addresses  from  logical  ones).  This  study  has  determined  that  the 
following  functions  will  be  performed  in  only  certain  SDPs  and  therefore 
should  be  thought  of  as  application  functions  of  the  DOS. 

• Command  verification  and  command  preprocessing  functions. 

• All  network-wide  file  management,  output  device  management,  and 
database  management  will  be  at  the  resource  providing  the  service  or 
if  the  device  is  unintelligent,  management  will  be  assigned  to  a 
designated  SDP  selected  to  manage  that  resource. 

• Global  monitoring  functions  for  the  purpose  of  assessing  global 
network  performance,  trending,  and  error  logging. 

• Network  reconf iguration : i.e,  warn  an  operator  to  shut  down  an  NIU, 

and  to  actually  shut  down  and  reactivate  NIUs  once  such  commands  are 
given  by  the  operator . This  function  will  also  provide  the  means  by 
which  a processor  (NIU  or  SDP)  may  be  initialized  with  a memory  load. 

6. 4. 4. 3 The  Distributed  OS  Components  of  the  DOS 

fbe  functions  listed  below  for  the  component  of  the  DOS  which  is  present  in 
every  NIU  and  SDP.  The  portion  which  is  resident  in  the  NIU  is  defined  as  the 
Network  Operating  System  or  NOS.  That  portion  which  is  resident  in  the  SDP 
will  be  an  interface  between  the  traditional  operating  system  running  in  the 
SDP  and  the  NOS.  The  functions  are  listed  in  their  probable  sequence  of 
execution . 

SDP  resident  portion  of  the  DOS: 

• The  SDP  will  contain  a set  of  commands  for  use  by  applications  in 
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specifying  requests  for  data,  sensor  values,  variables,  communication  with 
another  process,  etc.  Such  a command  may  be  GET_SENSOR_VALUE_( SENSOR) , 
for  example. 

• The  interprocess  communication  mechanism.  Once  a command  such  as  GET- 
SENSOR-VALUE  is  issued  by  the  application,  the  SDP  resident  portion  of  the 
DOS  determines  whether  the  sensor  is  local  or  remote,  and  if  remote, 
issues  a message  containing  a request  for  the  reading  of  the  sensor. 

• The  decision  of  whether  to  use  broadcast,  multicast,  or  point-to-point  IPC 
to  deliver  the  message  is  made  at  this  point.  Such  a decision  will  be 
based  on  the  needs  of  the  application  sending  the  message. 

• Other  Layer  7-5  functions  of  the  ISO/OSI  protocol  are  executed  as  needed. 

• At  layer  6 (presentation),  negotiations  between  the  sender  and  receiver 
will  determine  if  any  protocol  conversions  are  required.  Our 
recommendation  is  that  this  layer  should  be  null  for  IOC  due  to  the  use  of 
homogeneous  protocols. 

• Certain  layer  5 (session)  functions  are  then  performed  including 
segmentation  of  a long  message  into  pieces  that  the  NIU  can  handle,  if 
necessary.  Similarly,  reassembly  is  done  on  incoming  segments.  An  SDP 
header  containing  at  least  the  following  information  is  then  attached  to 
the  message  (or  segment) : 

- The  segment  number  of  the  current  transmission. 

Source  process  (physical  ID)  and  destination  process,  sensor, 
effector,  etc.  (logical  ID) 

- Indication  of  whether  point-to-point,  broadcast,  or  multicast  service 
is  to  be  used. 

Note  that  this  header  which  is  passed  to  the  NIU  will  be  reformatted  by  the 

layer  4 protocol  of  the  NIU.  For  example,  all  logical  addresses  will  be 

replaced  with  physical  addresses. 
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Will  Resident  Portion  of  the  DOS: 


• Once  a message  or  segment  is  received  from  the  host,  the  layer  4 functions 
are  performed . The  most  important  of  these  is  determining  a physical 
address  for  the  logical  destination  address.  The  operating  system  trade 
study  determined  that  a "cache"  of  frequently  requested  addresses  will  be 
maintained,  with  all  other  addresses  being  obtained  from  the  centralized 
name  server.  A request  for  the  address  will  be  broadcast  if  the  name 
server  is  unavailable.  Since  connection  service  is  to  be  used  at  layer  4, 
flow  control  will  be  achieved  through  the  credit  window  scheme.  The 
destination  NIU  is  contacted  to  determine  the  length  and  rate  of 
transmission  which  can  be  accepted. 

• Layer  3 functions  will  then  be  executed,  including  determining  routing  for 
any  internetwork  messages.  If  routing  tables  are  not  maintained  as  every 
IMIU  (left  as  a TBD  design  decision),  all  internetwork  messages  will  be 
sent  to  a designated  bridge  of  the  LAN  where  the  message  originates.  The 
bridge  s routing  table  will  be  utilized  to  forward  the  packet  on  its  way 
to  the  destination. 

Segments  will  be  divided  into  packets  and  transmitted  through  the  network 
using  the  layer  2 and  layer  1 protocols.  Variable  length  packets  will  be 
utilized  to  make  maximum  use  of  available  bandwidth.  Connectionless 
service  is  used  at  this  level. 

The  NOS  software  in  the  NIU  will  also  have  the  following  capabilities: 

• The  ability  to  broadcast,  multicast,  or  send  point-to-point  messages. 

• The  ability  to  place  connected  SDPs  on  or  off-line  when  commanded  to  do  so. 

• The  ability  to  monitor  the  NIU  in  terms  of  logging  transactions  and 
detecting  errors. 

• The  ability  to  place  the  NIU  on  or  off-line  when  commanded  to  do  so. 
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6.4.5 


Subsystem  Data  Processor 


The  Phase  B RF'P  identifies  the  need  for  a standard  Subsystem  Data  Processor 
(SDP).  This  study  concluded  that  this  level  of  commonality  is  appropriate  for 
IOC  but  should  not  preclude  future  options  to  support  growth  and  technology 
insertion.  However,  any  new  technology  processor  brought  into  the  program 
should  strongly  consider  maintaining  the  same  instruction  set  architecture 
(ISA)  to  maximize  software  recovery/transportability . To  support  the  expected 
storage,  computation  capability  and  data  transfer  rates  the  IOC  SDP  is 
characterized  as  follows: 

- Main  Memory:  4 megabytes 

- Computational  Speed:  2000  KOPS 

- DMA  Channel  Speed:  1MHZ,  16  bit  parallel 

These  requirements  were  established  based  on  subsystem  sizing  estimates  (with 
a sizable  margin  for  growth)  and  an  evaluation  of  what  the  technology  should 
support  at  the  time  (1988)  SDP  technology  will  be  selected. 

6.4.6  Onboard  Workstations 

The  Phase  B Reference  Configuration  indicates  three  basic  types  of  operator 
interfaces  to  distributed  workstations.  They  are: 

• Operations  Center  in  HAB  Module  2 

• Multi  Purpose  Applications  Consoles  (MPACs) 

• Portable  MPACs 


6-30 


Our  view  of  the  MPAC  characteristics  is  the  same  as  the  Reference 
Configuration.  They  are: 

• Easy  to  use  (keyboard,  displays,  etc.) 

• Lightweight,  power  efficient 

• Standard  interface  (100%  interchangeable) 

• Configurable  by  operator 

Functionally,  the  MPAC  hardware  and  software  should  provide  the  following 
capabilities : 

• Access  to  and  interaction  with  the  onboard  data  base. 

• Load  and  run  selected  application  programs  (initiated  by  operator 
actions)  that  are  executed  infrequently,  thereby  reducing  SDP  loads 
and  possibly  network  loads.  This  could  leave  the  SDPs  to  execute 
mostly  cyclic  programs. 

• Common  interface  for  core  and  payload  operators. 

• Commonality  with  ground  operator  interfaces,  which  simplifies 

training  for  inflight  operations. 

• Ability  to  define  (through  the  use  of  a standard  User  Interface 
Language  (UIL))  and  execute  ad-hoc  operations  on  data  contained  in 
the  onboard  or  ground  data  bases.  This  would  include  the  generation 
of  displays  for  trend  analysis,  subsystem  monitoring,  etc. 

Finally,  the  possibility  of  having  the  same  processor  in  the  SDP,  the 
Operations  Center  (in  HAB2)  and  MPAC  should  be  studied  to  significantly  reduce 
costs,  maintenance  and  training. 

6.4.7  Operational  Data  Base 

6.4. 7.1  Onboard  Operational  Data  Base  Management  System  (ODBMS) 
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Current  estimates  of  the  onboard  ODBMS  Storage  Requirements  for  IOC  are  as 
follows : 

1)  The  DMS  must  provide  the  capability  for  approximately  256  Mbytes  of 
non-volatile  storage  for  the  core  subsystems  based  on  the  following: 

90  Mbytes  application  program  loads 
10  Mbytes  checkpoints 
10  Mbytes  engineering  data 
10  Mbytes  procedures 
10  Mbytes  schedules 

50  Mbytes  telemetry  data  acquisition 
76  Mbytes  margin 

2)  Storage  requirements  for  the  payload  ODBMS  are  not  as  easily 
estimated.  For  this  report  we  are  assuming  that  the  payload  ODBMS 
storage  requirements  are  the  same  as  those  for  the  core  ODBMS  (256 
Mbytes).  As  payload  requirements  are  better  understood  this  estimate 
will  be  refined. 

The  ODBMS  which  provides  this  storage  can  be  structured  as  presented  in  Figure 
6.4-3.  Separate  ODMBS  services  exists  in  the  Core  Local  Area  Network  (CLAN) 
and  the  Payload  Local  Area  Network  (PLAN).  These  ODBMS' s are  homogeneous  and 
communicate  to  support  ancillary  data  distribution,  and  other  standard  core 
services . 

The  data  acquisition  interface  to  the  ODBMS  is  presented  in  Figure  6.4-4.  The 
subsystems  collect  data  into  records  and  deliver  these  records  to  the  ODBMS  on 
a dynamically  negotiated  basis.  (More  details  are  given  in  the  Data  Base 
Management  trade  study,  Section  1.5.2. 1.)  The  ODBMS  supports  Telemetry 
Traffic  Control  (TTC)  in  building  Telemetry  Buffer  Units  (TBU's)  for  delivery 
to  the  communication  toggle  buffers.  The  same  interface  exists  for  PL/EXP 
except  the  PL/EXP  delivers  data  in  the  CCSDS  telemetry  packet  format.  The  TTC 
segments  these  packets  (if  necessary)  when  building  the  TBU's. 

For  the  build-up  of  the  onboard  mass  storage  configuration  it  is  recommended 
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Figure  6.4-3.  Onboard  Data  Base  Management  System  Interfaces 


that  the  scenario  presented  in  Figure  6.4-5  be  used.  In  this  configuration 
the  SDP/I\IIU  nodes  manage  local  non-volatile  memory  for  the  first  two  flights 
and  then  mass  storage  units  are  delivered  in  the  first  pressurized  module 
(HM1).  The  mass  storage  units  are  distributed  into  the  pressurized  modules. 
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T oggle  to 
Comm  l/F 


Figure  6.4-4.  TTC  Interface 


The  recommended  mass  storage  integration  with  other  Onboard  SSDS  elements  is 
presented  in  Figure  6.4-6.  In  this  configuration  the  mass  storage  is  on  a 
standard  local  bus  (serial  or  parallel  to  be  determined)  on  the  backend  of  an 
IMIU . 


6 . 4 . 7 . 2 Mass  Storage  Devices 

The  SSDS  will  have  many  applications  that  will  use  many  different  kinds  of 
mass  storage  devices.  The  three  most  driving  onboard  space  station 
application  areas  are: 
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Alternative  1 


Figure  6.4-5.  OOBMS  Flight  Build-Up 
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Figure  6.4-6.  ODBMS  Mass  Memory  Integration 


1. 


Onboard  Data  Base  Management  System  (ODBMS)  mass  store. 


2.  High  rate  data  buffer. 

3.  Payload  Local  Area  Network  (PLAN)  communication  data  buffer. 

The  requirements  and  design  characteristics  for  these  applications  were 
developed  through  mission  set  analysis,  simulations,  function  set  analysis, 
and  engineering  design  judgement.  The  derived  requirements  and  design 
characteristics  for  each  of  the  above  applications  are: 

1.  DBMS  MASS  STORE 
2xl09  BITS  CAPACITY 

10  Mbit/second  transfer  rate 
40  millisecond  access  time 

2.  HIGH  RATE  DATA  BUFFER 
2x10**  bits  capacity 
300  Mbits/second  in 

600  Mbits/second  out  (assuming  two  KSA  links) 

3.  PLAN  COMMUNICATION  DATA  BUFFER 

9 

12x10  bits  capacity 
10  Mbits/second  transfer  rate 

The  recommended  mass  storage  option  for  all  of  the  above  application  areas  is 
eraseable  optical  disk  if  the  technology  can  be  developed  and  demonstrated  by 
IOC.  This  recommendation  is  based  on  the  desire  for  hardware  commonality 
across  all  onboard  mass  storage  applications.  The  driving  requirement  is  the 
high  rate  data  buffer  where  the  optional  disk  offers  random  access  capability 
(eliminate1 s need  for  subsequent  bit/packet  reversal),  enhances  buffer  design 
flexibility  and  provides  significant  capacity  for  growth. 

If  eraseable  optical  disk  cannot  be  developed  as  recommended  for  IOC  then 
magnetic  disk  (Winchester  Technology)  should  be  used  for  the  ODBMS  mass  store, 
and  magnetic  tape  for  the  buffers.  Regardless  of  the  technology  used  for  the 
IOC  configuration,  eraseable  optical  disk  should  be  developed  for  use  in  the 
growth  Space  Station. 
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The  Function  Data  Base  contains  sizing  estimates  for  secondary  storage  and 
archival  storage.  These  are  yet  to  be  evaluated  in  detail  and  will  be 
included  in  a future  update  to  this  report. 

6.4.8  Communication  Gateway 

The  "communication  gateway"  is  a term  that  is  associated  with  the  functions 
performed  to  receive  and  deliver  messages  into  and  out-of  the  onboard  local 
area  networks.  These  functions  are  actually  distributed  into  three  DMS 
functions;  data  acquisition  (DATA  ACQ),  Telemetry  Traffic  Control  (TTC) , and 
Telecommand  Interface  (TLMCMD  I/F),  and  also  functions  in  the  Communication 
Subsystem.  The  interface  is  depicted  schematically  in  Figure  6.4-7.  The  DMS 
functions  are  performed  in  the  SDP's  attached  to  the  local  area  networks  and 
also  mass  storage  devices  managed  by  the  DMS.  The  Communication  Subsystem 
functions  are  performed  by  a baseband  processor  (possibly  an  SDP),  mass 
storage,  toggle  buffers  and  RF  processors. 

The  DATA  ACQ  function  collects  data  from  subsystems  or  PL's  on  a periodic  or 
aperiodic  basis,  as  required,  in  support  of  the  return  link.  This  is  done  in 
cooperation  with  the  ODMBS . The  TTC  function  assembles  segments  of  this  data 
into  Telemetry  Buffer  Units  (TBU's)  along  with  return  link  telecommands  or 
telecommand  acknowledgements.  These  TBU's  are  transmitted  to  the 
communication  subsystem  for  the  real-time  return  link  (SSA).  The  TLMCMD  I/F 
function  disassembles  forward  link  TBU's. 

The  TLMCMD  I/F  uses  the  addressed  provided  in  segments  of  the  forward  link 
TBU's  to  deliver  data  and  commands  to  core  and  PL  local  area  networks. 
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6.4.9  TRAFFIC  ANALYSIS 

The  following  two  sections  derived  the  network  traffic  requirements  and 
the  network  packet  sizing.  The  requirements  are  presented  In  terms  of 
messages  per  second,  a more  meaningful  traffic  parameter  than  bytes  per  second. 

6. 4. 9.1  TRAFFIC  SIZING 

Analysis  of  the  network  traffic  model  (both  core  and  payload  networks) 
shows  the  communication  and  tracking  NIU  receives  over  10%  of  the  total 
traffic  for  both  the  core  and  payload  networks. 


The  network  traffic  model  was  derived  from  the  McDonnell  Douglas 
Requirements  Data  Base  (Appendix-1)  using  an  analysis  tool  developed  In  PL/I. 
The  tool  allows  functions  In  the  Requirements  Data  Base  to  be  arbitrarily 
distributed  across  a multi-computer  environment.  The  process  allows  the 
operator  to  Interactively  specify,  for  example: 

Computer  Computer  Computer  Computer 

1 2 N-1  N 


Function  # 

1.1.1 


Function  # 

2.1.1 


External  1 
External  2 


External  3 


1.1.2 


4.3.1 


From  this  Input,  a search  of  the  data  base  Is  made  to  determine  the 
following  reports: 

Computer  1 to/from  Computer  2 

Computer  1 and  2 to  External  Sets  1 and  2 

Computer  1 and  2 to  External  Set  3 


Proper  selection  of  the  Inputs,  functions  and  externals,  resulted  In 
statistical  reports  to  evaluate  the  I/O  requirements.  From  these  Inputs  the 
following  statistics  were  determined: 

Subsystem  to  subsystem  I/O 
Subsystem  to  subsystem  sensors/effectors 
Subsystem  to  operational  data  base,  ancillary  data 
Subsystem  to  displays 

Subsystem  to  Comm  for  telemetry,  operations  Instrumentation  data 
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The  network  traffic  model  was  developed  from  several  sources: 

(1)  Analyses  of  Functions  Data  Base  I/O  Relationships 

(2)  Engineering  Modifications  to  (1)  Above 

(3)  Engineering  Judgement 

Additions  to  the  Network  Traffic  Model  Included: 

(1)  Telemetry  Data 

(2)  Operations  Instrumentation  Data 

(3)  Ancillary  Data 

(4)  Ground  Forward  Commands 

Table  6. 4. 9. 1-1  Identifies  specific  assumptions  employed  In  the  network 
traffic  analysis.  Figure  6. 4. 9. 1-1  and  6. 4. 9. 1-2  show  the  processing 
distribution  for  both  the  core  and  payload  networks.  Figure  6. 4. 9. 1-3  shows 
a detailed  payload  distribution  for  the  payload  network.  The  Illustrated 
payload  attachments  were  arbitrarily  made  and  are  not  Important  to  the  network 
traffic  load.  Only  low  data  rate  traffic  under  1 MBPS  was  considered  In  the 
payload  traffic  model.  Payload  traffic  with  data  rates  greater  than  1 MBPS  Is 
hardwired  to  the  C&T  subsystem. 

TABLE  6. 4. 9. 1-1  NETWORK  I/O  TRAFFIC  ASSUMPTIONS 
o Requirements  Sources 

- Mission  data  sets  for  P/L  telemetry  rates  (Includes  only  P/L 
Instruments  with  data  rates  less  than  1 MBPS) 

- Analysis  of  core  traffic  results  and  engineering  judgement  to  model 
remaining  non-telemetry  payload  network  traffic  nodes. 

- Assume  all  P/Ls  run  simultaneously  (some  have  duty  cycles  less  than 
24  hours/day) 

o Topology 

- Integrated  P/L  Instrument  data  access  off  backend  of  SDPs 

- Flles/Data  stores  In  each  Subsystem  SOP 

- DMS  ODB  has  It's  own  SDP 

- P/L  flles/data  stores  In  P/L  SDPs 

- P/L  data  base  In  P/L  network 
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TABLE  6. 4. 9. 1-1  (CONTINUED) 


o Packet/Message  Length 

- Message  length  equals  packet  length 

o Telemetry 

- 25  KBytes/sec  per  Subsystem 

- 1 KByte  Message  size  to  satisfy  Consultative  Committee  for  Space  Data 
Systems  (CCSDS)  efficiency 

- Telemetry  messages  sent  from  P/L  network  to  C&T  node 
o Displays 

- Multiple  panels  possible  per  Subsystem  per  MPAC 

- Four  Windows  per  MPAC  possible 

- One  2 KByte  message/sec  per  Subsystem  to  MPAC 

o Overhead 

- OSI/CCSOS  message  overhead  not  Included 

o Ancillary  Data  (AD) 

- Subsystems  send  AD  to  DMS  ODB 

- DMS  ODB  blocks  AD  and  sends  to  P/L  Network  ODB 

- P/L's  read  AD  from  P/L  ODB  as  required 

o Ground  Forward  Commands  (GFC) 

- Comm  receives  GFC  for  each  subsystem 

- Comm  routes  GFC  to  Individual  Subsystems 

- Dependent  on  CMD  VAL  Implementation 

- P/L  GFC  are  routed  to  P/L  network  for  response 

- 0.1  message/sec  per  subsystem 

o Operations  Instrumentation  Data  (OID) 

- OID  collected  by  each  subsystem  from  backend 

- Subsystems  send  blocked  OID  to  COMM  for  downlink 


6-40 


ORIGINAL  PAGE  IS 
PC  POOR  QUALITY 


ORIGINAL  PAGE  IS 
OF  POOR  QUALITY 


Lab  1 


(Mem.  Config  3) 
ECLSS 
Crew  Sys 
Str  & Mech 
(Mem.  Config  4) 
DMS ODB 


1 1 



f 1 

n r Lr 

i 

1 u 

CMC 

Star 

Tracker  I 

~i  i — i 

(6)  (2) 

Transverse  Boom 


ACT 

~ 


CommlJ— I THM  J-J  pwr  J-l  THM  J-J 


Transverse  Upper  Keel 
Boom  Ext 


T ransverse 
Boom 


Transverse 

Boom 

Ext 


Comm 

1/F 


ECLSS  J Pwr  J THM  J 


Prox 

Ops 


HM2 


Logistics 

S&E 

Logistics 

Module 
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Figure  6.4.9. 1-2.  Processing  Distribution  for  Payload/Ewperiment  LAN 


Figure  6.4.9.1-3.  Typical  Connectivity  of  Low  Rate  Payload  Experiments 


Table  6. 4. 9. 1-2  and  6. 4. 9.1-3  show  the  network  traffic  results  for  the 
core  and  payload  networks,  respectively.  These  tables  show  for  the  core 
network  the  traffic  due  to  telemetry  Is  approximately  60%  of  the  total  load 
and  the  elemetry  traffic  on  the  payload  network  Is  over  80%  of  the  total 
traffic  load. 

6. 4. 9. 2 PACKET  SIZING 

A 2048  byte  packet  has  been  selected  as  the  baseline  packet  size  for 
network  trades,  analyses  and  design  tasks.  The  MDAC  function  data  base  was 
accessed  to  Identify  potential  network  messages.  These  were  screened  to 
Identify  those  which  enter  the  network.  Figure  6. 4. 9. 2-1  shows  that  the 
majority  of  the  messages  entering  the  network  are  telemetry  messages  whose 
length  Is  less  than  2048  bytes.  Figure  6. 4. 9. 2-2  shows  that  a 2048  byte 
packet  can  accommodate  95%  of  all  network  messages  without  segmenting  messages. 
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PACKET  SIZE  (KILOBYTES) 


6.4.10  Fault  Tolerance 


The  explicit  fault  tolerance  requirement  in  the  Phase  B RFP  is  that  "critical 
subsystems"  be  fail -operational,  fail-safe,  restorable  (FO/FS/R).  The  final 

FO/FS/R  decisions  of  which  subsystems  or  their  functions  are  critical  has  not 
been  made.  The  Phase  B SE&I  IMASA/Contractor  teams  will  study  this  issue.  At 
this  stage,  the  SSDS  A/A  team  believes  the  following  functional  areas  are  the 
most  critical: 

Docking/Berthing  Operations 

Proximity  Operations  (NSTS,  COP,  Free-flyers,  OTV,  OMV) 
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Figure  6.4-7.  Communication  Gateway 
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Transfers  of  Particular  Fuels  (e.g.,  OTV  fueling) 


A key  point  is  that  it  is  unlikely  that  any  subsystem  must  be  FO/FS/R  with  no 
interruptions  in  functionality  at  all  times.  If  this  were  really  true,  the 
only  solution  is  triple  (or  higher)  redundant  simultaneous  execution.  Shuttle 
experience  has  shown  that  assigning  redundant  computers  has  a large  impact  on 
the  system  design  and  verification  is  extremely  costly.  This  should  be 
avoided  for  Space  Station. 

The  Space  Station  environment  on  orbit  is  much  more  benign  than  the 
atmospheric  flight  phases  of  Shuttle.  The  key  to  the  solution  is  the 
restoration  time.  It  seems  reasonable  that  a design  which  allows  the  loss  of 
a few  seconds  during  recovery  is  acceptable  for  most  subsystems  if  not  all. 

The  Fault  Tolerance  option  development  and  Trade  Study  documentation  provides 
more  supporting  detail  and  analysis  on  this  subject.  The  presentation  of 
this  work  is  primarily  in  the  form  of  what  could  be  done  to  handle  various 
levels  of  subsystem  availability  and  fault  recovery  time.  The  remaining 
sections  below  summarize  the  four  basic  areas  of  fault  tolerance: 


• Replication 

• Fault  Detection 

• Damage  Assessment 

• Error  Recovery 


6.4.10.1  Replication 

Several  functions  may  have  the  need  for  a very  high  probability  of  detection 
of  faults,  with  enough  time  to  allow  recovery  by  use  of  a checkpoint  restart. 
The  recommendation  is  that  such  functions  be  designed  for  duplex  operation  in 
critical  time  phases  with  at  least  one  spare  SDP.  The  system  configuration  is 
such  that  the  preferred  spare  is  the  SDP  in  the  same  triad  with  the  primary 
SDP.  Reference  Figure  6.6-1  for  the  overall  architecture  that  indicates  the 
SDP  triads.  However,  the  network  is  connected  such  that  any  other  SDP  can 
assume  the  processing  task  by  communications  over  the  network  instead  of  more 
directly  through  an  SDP/NIU  set.  While  this  connection  exceeds  FO/FS/R 
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requirements,  there  is  a substantial  improvement  in  overall  reliability, 
especially  in  man-tended  operations  when  no  one  is  onboard  to  replace  failed 
SDPs  within  a few  hours  or  days  of  the  failure.  The  operating  system  will  be 
designed  so  that  the  application  is  unaffected  by  the  location  of  the  SDP 
(other  than  time  delays  for  network  communications). 

Subsystems  which  have  no  need  for  very  high  probability  of  detecting  a fault 
will  execute  in  simplex.  This  mode  has  the  important  advantage  of  minimizing 
Space  Station  resources  for  power  and  cooling. 

6.4.10.2  Fault  Detection 

The  recommended  fault  detection  is  based  on  separating  the  "system"  function 
of  detecting  a faulty  unit  (SDP,  NIU,  network)  from  the  subsystem  function  of 
detecting  its  own  processing  faults.  The  first  part  of  fault  detection  is  the 
use  of  common  hardware  fault  detection  techniques  such  as  built-in  test 
equipment  (BITE),  parity  types  of  detection  (including  cyclic  redundancy 
checks,  error  correction  coding,  and  other  multiple  bit  protection),  and 
watchdog  timers  at  major  hardware  interfaces.  The  recommended  second  part  of 
fault  detection  is  a background  or  periodic  self-test  program  execution,  which 
tests  as  much  of  the  unit  (SDP,  NIU,  or  network)  as  possible  without 
interference  with  any  application  or  operating  system  function.  This 
combination  is  usually  able  to  detect  solid  faults  with  probabilities  of  about 
95  percent.  The  recommended  third  part  of  fault  detection  is  the  inclusion  in 
the  operating  system  of  a periodic  monitor  which  talks  with  each  SDP  and  NIU 
to  assure  basic  stopped/running  status.  It  is  recommended  that  this  monitor 
function  execute  in  the  duplex  operation  mode. 

The  recommended  fourth' part  of  fault  detection  requires  the  help  of 
application  programs  executing  in  duplex  or  higher  redundancies  to  achieve 
fault  detection  much  above  the  95  percent  level,  and  detection  of  trarsient 
faults.  Presumably,  these  applications  have  been  designed  to  cross  compare 
sensor  inputs  and  computed  results  as  part  of  the  applications’  own  fault 
detection.  A method  will  be  provided  for  the  application  to  alert  the 
operating  system  of  failure  to  compare,  especially  persistent  miscompares, 
including  the  option  to  request  termination  of  the  application  followed  by  a 
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reload  from  mass  storage  and  resumption  from  a checkpoint.  (Note  that  the 
effectiveness  of  this  fourth  part  depends  on  the  maturity  and  thoroughness  of 
testing  of  the  applications.  Use  is  expected  to  be  restricted  to  the  more 
critical  core  functions,) 

6.4.10.3  Damage  Assessment 

A two  part  approach  is  recommended  for  damage  assessment.  The  intent  is  both 
to  determine  which  of  a duplex  pair  is  faulty  (if  this  is  not  immediately 
obvious)  and  to  isolate  the  faulty  component  adequately  for  repair  and 
maintenance  activities.  Many  faults  must  be  assessed  immediately  in-place  in 
order  to  minimize  the  number  of  very  expensive  problems  which  cannot  be 
recreated  on  a test  bench.  The  first  part  of  the  assessment  is  to  record  any 
unusual  conditions  (such  as  input/output  errors,  BITE  detected  errors,  or 
machine-check  indications).  These  conditions  are  routinely  recorded  as  part 
of  the  operating  system  functions.  The  second  part  of  the  assessment  is  to 
immediately  execute  a complete  self-test  of  any  suspect  unit  and  to  record  the 
results.  Unless  the  unit  is  totally  bad  (e.g.,  loss  of  a power  supply),  the 
self-test  can  often  both  confirm  which  unit  is  faulty  and  isolate  which  orbit 
replaceable  unit  (ORU)  needs  to  be  exchanged  to  restore  the  unit  to 
operational  status  as  a spare. 

6.4.10.4  Error  Recovery 

The  recommended  approach  to  error  recovery  is  to  have  each  application 
generate  any  checkpoints  which  are  required  for  timely  resumption  following  a 
failure.  Specification  of  specific  data  content  and  checkpoint  intervals  will 
be  a part  of  the  detail  design  of  each  application,  and  is  beyond  the  scope  of 
the  current  study.  However,  the  operating  system  will  provide  the  basic 
capability  to  write  and  recall  checkpoints  up  to  some  redundancy  level  (for 
example,  keep  only  the  last  5 checkpoints),  and  to  detect  the  important  case 
of  a checkpoint  which  was  incomplete  because  the  failure  occurred  in  the 
middle  of  writing.  Verification  of  the  contents  of  the  checkpoint  is  the 
responsibility  of  each  application  program,  beyond  the  usual  checksum  or 
cyclic  redundancy  check  provided  by  the  operating  system  or  storage  medium. 
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6.4.11  Time  Management 


The  four  topics  of  time  management  in  the  onboard  data  management  system  are: 
time  reference  source;  time  distribution;  time  tagging  of  data;  and  frequency 
distribution.  Reference  the  Time  Management  Option  Development  report  for 
more  background  detail. 

6.4.11.1  Onboard  Reference  Source 

Both  the  global  positioning  system  (GPS)  and  a master  timing  unit  (MTU)  are 
recommended  as  the  time  reference  sources.  The  local  oscillators  of  each  NIU 
and  SDP  are  available  as  emergency  references  if  both  the  GPS  and  MTU  become 
unavailable  (which  exceeds  the  FO/F'S/R  requirement) . The  order  of  precedence 
is  the  GPS,  the  MTU,  and  the  local  oscillators.  The  primary  reason  for  both 
the  GPS  and  the  MTU  is  the  lack  of  GPS  during  early  buildup. 

6.4.11.2  Time  Distribution 

The  recommended  method  of  time  distribution  throughout  the  DMS  is  via  the 
network.  The  three  steps  are:  equalize  the  time  in  the  NIU  attached  to  the 

reference  source  (GPS  or  MTU)  to  match  the  reference  source;  distribute  time 
from  this  NIU  to  all  other  NIUs  in  the  network;  equalize  time  in  each  SDP  to 
the  time  in  its  attached  NIU.  Details  of  the  method  are  described  in  the 
options  development  report  on  time  management.  The  expectation  is  a time  skew 
within  the  network  of  less  than  one  millisecond,  and  probably  less  than  0.1 
milliseconds.  The  process  will  be  repeated  every  one  to  ten  seconds  to 
prevent  short  term  drifts  at  any  NIU  or  SDP  from  becoming  excessive. 

6.4.11.3  Time  Tagging  of  Data 

Two  forms  of  time  must  be  provided.  One  form  is  continuous,  with  no 
discontinuti.es  at  points  such  as  end  of  day,  end  of  year,  or  leap  seconds. 

This  time  form  is  the  international  time  (TAI)  recommended  by  CCSDS  for 
ephemeris  time.  The  other  form  includes  leap  second  corrections  for  the 
slowing  rotation  of  the  earth.  The  continuous  form  will  be  Earth  Mean  Equator 
1950  (EME-50).  The  discontinuous  form  will  be  Universal  Coordinated  Time 
(UTC) . 
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Standard  time  formats  will  be  used  for  communication.  Selection  of  specific 
standard  formats  is  not  a key  design  driver  at  this  point  in  the  project. 

6.4.11.4  Frequency  Distribution 

Both  the  GPS  and  MTU  provide  precision  frequency  sources.  The  recommendation 
is  to  use  the  MTU  as  the  frequency  reference  source,  since  the  MTU  is 
available  throughout  buildup.  Frequency  distribution  will  be  by  direct  wiring 
to  each  required  user.  The  communications  subsystem  is  expected  to  be  the 
prime  user. 

6.5  Operational  Scenarios 
6.5.1  Initialization 

The  onboard  data  management  system  will  need  to  be  intialized  on  orbit  when 
the  first  structures  are  in  place,  during  buildup  and  operation  if  an  upgrade 
requires  removing  power  from  existing  modules,  and  as  the  recovery  mode  from 
major  loss  of  power . The  source  of  software  programs  is  assumed  to  be  one  or 
more  mass  storage  devices  onboard  the  Space  Station,  and  accessible  through 
the  core  LAW.  These  mass  storage  devices  are  initially  loaded  on  the  ground, 
with  subsequent  modifications  by  uplink  data  (either  by  onboard  requests  or 
ground  initiated  updates)  or  by  replacement  at  a resupply  cycle.  This  section 
describes  an  approach  to  the  "cold  start"  of  the  entire  data  system. 
Initialization  of  individual  subsystems  during  build-up,  upgrades,  and  failure 
recovery  is  a subset  of  these  procedures. 

This  description  assumes  that  the  various  units  (SDPs,  NIUs)  may  be  turned  on 
in  any  order.  Further1,  each  SDP  and  WIU  is  assumed  to  have  a non-volatile 
memory  (ROM)  that  contains  the  minimal  program  necessary  to  load  (boot)  the 
operating  system  into  the  SDP  or  WIU  through  the  network.  This  initial 
program  load  (IPL)  ROM  is  forced  to  execute  when  power  is  first  applied  to  the 
unit,  either  by  direct  execution  or  by  first  copying  the  IPL  program  from  the 
ROM  into  main  memory. 


6-54 


The  general  procedure  has  three  phases.  First,  each  NIU  attached  to  a load 
source  (mass  storage)  recognizes  this  function  by  its  physical  identification, 
and  uses  its  direct  attachment  to  load  itself  with  the  network  operating 
system  (NOS)  and  a the  full  set  of  mass  storage  control  programs.  Second,  the 
other  NIUs  are  loaded  with  the  NOS  through  use  of  the  mass  storage  on  the 
LAN.  Third,  the  SDPs  are  loaded  using  the  NOS  contained  in  their  attached 
NIUs.  At  this  point  the  crew  or  ground  will  have  basic  communication  with  the 
data  system  to  control  subsystem  initialization  either  by  predefined  tables  or 
by  manual  overrides  of  these  tables. 

6.5. 1.1  NIU  Attached  to  Mass  Storage 

The  ROM  in  all  NIUs  will  be  the  same.  When  this  ROM  is  given  control  at  power 
application,  the  program  will  use  the  physical  identification  of  the  NIU  to 
determine  whether  this  NIU  is  attached  to  a mass  storage,  and  follow  this 
procedure  or  the  one  in  the  next  section. 

The  NIU  will  first  access  a predefined  location  on  the  mass  storage  to  read 
the  directory  of  the  contents  of  the  mass  storage.  The  directory  will  next  be 
searched  for  the  name  of  the  entry  for  the  network  operating  system  (NOS).  If 
no  such  entry  is  found,  then  this  NIU  is  not  really  a load  source,  and  will 
revert  to  the  procedures  of  the  next  section.  The  directory  entry  will 
identify  key  items  for  loading  the  program  into  the  NIU,  typically  the 
starting  address  on  the  mass  storage,  the  load  address  in  the  NIU  memory,  the 
length  of  the  program,  and  the  address  to  branch  to  after  the  program  is 
loaded.  This  program  is  then  loaded  into  the  main  NIU  memory  and  started  in 
execution  to  complete  the  formal  IPL  procedure  of  the  NIU. 

The  program  which  was  loaded  may  be  the  full  NOS  or  may  be  the  next  step  of  a 
multiple  stage  IPL  procedure.  Experience  indicates  that  the  maximum 
flexibility  results  from  loading  only  a small  initial  program  through  the 
formal  IPL  (perhaps  1024  bytes).  This  small  program  then  loads  the  main 
program.  The  current  recommendation  is  to  include  such  a minimal  program  in 
the  ROM  of  the  NIU. 
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At  the  conclusion  of  this  step,  the  l\IIU  will  announce  itself  to  the  onboard 
LAN  (log-on)  as  a source  of  program  loads  for  any  other  device.  This 
information  is  needed  by  bridges  or  gateways  in  order  to  transfer  messages 
between  local  area  networks. 

^•5.1.2  NIUs  Not  Attached  to  Mass  Storage 

Any  NIU  not  attached  to  mass  storage  cannot  procede  until  at  least  one  mass 
storage  has  announced  itself  on  the  LAN,  as  above.  The  ROM  in  these  NIUs  will 
detect  the  presence  of  a load  source  somewhere  in  the  LAN  by  periodically 
attempting  to  attach  itself  to  any  load  source,  perhaps  once  per  second.  The 
request  is  repeated  indefinitely  until  acknowledged  so  that  if  the  mass 
storage  is  not  currently  available,  or  if  the  NIU  is  turned  on  before  the  mass 
storage,  the  NIU  IPL  will  simply  wait  until  a load  source  is  available. 

Once  the  attachment  is  made  between  the  NIU  and  the  mass  storage  (via  the 
LAN),  the  ROM  program  will  request  that  the  file  named  NOS-IPL  (or  equivalent) 
be  sent  to  the  NIU.  This  request  will  be  repeated  indefinitely  or  until  a 
successful  copy  is  obtained.  After  the  file  is  loaded,  the  ROM  program  will 
branch  to  a predefined  main  memory  location  in  the  NIU  to  begin  execution  of 
the  loaded  program,  completing  the  formal  IPL  of  the  NIU. 

Again,  the  file  may  be  only  the  first  step  of  a multiple  stage  IPL  procedure. 
If  the  NIUs  are  not  all  identical,  it  is  likely  that  the  first  stage,  above, 
will  load  the  common  part  of  the  NOS,  and  a later  stage  will  load  any  device 
dependent  NOS . 

6-51. 3 SDP  Initialization 

The  SDP  contains  a ROM  with  the  minimal  program  needed  to  communicate  to  the 
NOS  in  the  attached  NIU,  and  through  the  NOS  to  a mass  storage  on  the  LAN. 

This  SDP  IPL  program  may  be  executed  either  directly  or  after  being  loaded 
into  the  main  memory  of  the  SDP. 
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The  first  step  of  the  SDP  IPL  will  be  to  determine  if  the  attached  NIU  has 
been  loaded  with  the  IMOS.  The  SDP  IPL  will  therefore  interrogate  the  NIL) 
until  the  status  shows  that  the  NOS  is  available  for  use.  The  ROM  will  then 
register  (log  on)  to  the  NOS,  using  the  physical  identification  of  the  SDP  to 
assure  a unique  name  within  the  network.  Next  the  SDP  ROM  will  request  that 
file  SDP-IPL  (or  equivalent)  be  copied  from  the  mass  storage  to  the  SDP  by  use 
of  the  LAN.  At  completion  of  this  procedure,  the  ROM  program  will  branch  to  a 
predefined  address  in  the  SDP  main  memory  completing  the  formal  SDP  IPL. 

As  with  the  NIU,  this  may  be  only  the  first  step  of  a multiple  stage  IPL 
procedure . Other  stages  may  complete  the  loading  of  a full  operating  system, 
location  dependent  programs,  and  special  applications  such  a3  the  ODBMS 
software . 

6. 5. 1.4  Application  Programs 

During  the  early  build-up  phases  the  initialization  process  may  wait  at 
completion  of  the  above  steps  until  a crewman  or  the  ground  directs  further 
loading  of  particular  programs  into  each  SDP.  Alternatively,  a set  of  tables 
on  mass  storage  may  define  a default  configuration  of  SDPs  and  workstations  to 
be  automatically  loaded  and  executed  as  the  last  steps  of  the  IPL.  The 
approach  recommended  is  to  have  both  a table  of  default  assignments  to  be 
started  automatically,  and  the  capability  to  move  subsystem  processing  within 
the  onboard  network  by  modification  of  the  tables. 

6.5.2  Subsystem  Control 

Control  of  the  onboard  SSDS  and  associated  subsystems  is  nominally  automatic. 
However  manual  overrides  via  direct  keyboard  inputs  from  an  onboard  MPAC  or 
from  telecommands  from  the  ground  will  be  provided.  It  is  envisioned  that  all 
subsystems  can  be  controlled  in  this  manner.  This  inplies  there  will  be  no 
dedicated  manual  switches  onboard. 
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The  ground  telecommands  will  be  in  one  of  two  forms: 


• equivalent  MPAC  keyboard  entries 

• special  commands 

The  "equivalent  MPAC  keyboard  entries"  option  has  several  advantages.  First, 
it  minimizes  the  onboard  impact  of  ground  originated  commands  since  the  same 
onboard  command  processing  software  can  be  used  regardless  of  the  source  of 
the  command.  Secondly,  this  approach  provides  commonality  between  ground  and 
onboard  control  functions.  A ground  operator  would  make  the  same  keystrokes 
on  his  MPAC  as  would  the  onboard  operator  to  accomplish  a given  control 
operation . 

Special  commands  would  be  those  for  which  no  equivalent  onboard  command 
capability  exists.  One  example  might  be  the  capability  to  update  the  Space 
Station  state  vector  in  the  event  of  a GPS  system  failure. 

Subsystems  will  normally  have  pre-built  displays  and  keyboard  entries  to 
manually  monitor  and  control  their  operations.  For  unplanned  situations,  a 
user  interface  language  (UIL)  will  allow  general  access  to  subsystem  data 
through  the  operational  data  base  and  provide  the  capability  to  construct 
displays  and  control  sequences  to  monitor  and  control  operations. 


6.5.3  Facilities  Management 

This  section  presents  the  centralization  aspect  of  our  onboard  distributed 
system  definition.  The  strawman  system  is  primarily  distributed  as  indicated 
in  the  memory  conf igur&tion  summary  in  Section  6.3  and  in  Section  6.6. 
However,  a set  of  functions  were  collected  together  and  defined  as  Facility 
Management  to  basically  provide  centralized  knowledge  and  control  o*  onboard 
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operations.  In  summary,  the  key  operations  performed  by  Facilities  Management 
(Tables  6. 2-1/6. 8-1)  are: 

• Checking  of  restricted  commands  generated  onboard  and  from  the  ground 

• Onboard  coordinated  operations  control 

• Centralized  collection  of  key  health  and  status  data  from  subsystems 
and  any  safety  related  data  from  the  payloads 

• General  diagnostic  and  systems  test  and  evaluation 

The  Task  1 Functional  Requirements  Report  and  the  above  referenced  tables 
provide  more  details  regarding  these  functions. 

Restricted/constrained  commands  are  those  core  and  payload  commands  whose 
execution  scheduling  is  dependent  on  specific  Space  Station  event  and  resource 
conditions.  Onboard  generated  commands  are  checked  onboard.  Ground  supplied 
restricted  commands  may  be  pre-checked  on  the  ground,  but  the  final  execution 
decision  is  made  onboard.  Command  and  resource  management  is  addressed  in 
Section  4.0  of  this  Task  Report. 

Facility  Management  coordinated  operations  control  and  system  monitoring  is 
raised  to  a summary  level  for  crew  casual  monitoring.  The  FM  caution  and 
warning  system  will  alert  the  crew  to  significant  problems  and  indicate  the 
problem  area.  At  this  point,  the  crew  can  bring  up  system  and  subsystem 
displays  for  more  information.  FM  also  provides  diagnostic  and  system  test 
support.  The  operators  can  request  more  detailed  data,  request  data  for 
trends,  etc. 

FM  displays  are  ideal  for  the  Operations  Center  presented  in  the  Reference 
Configuration  which  has  large  display  equipment.  However,  each  workstation 
will  provide  caution  and  warning  alerts,  so  that  the  crew  can  access  the 
nearest  unit. 
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6.5.4  Telemetry  and  Commands 

The  onboard  SSDS  interfaces  to  other  SSPE's  through  the  communication 
gateway.  This  gateway  handles  the  return  and  forward  SSA  and  KSA  links  to 
TDRSS  as  well  as  other  communication  links.  The  SSDS  interface  to  the 
communication  subsystem  for  utilization  of  some  portion  of  the  TDRSS  KSA  and 
SSA  links  is  the  subject  of  this  section.  Other  links  are  discussed  elsewhere 
(i.e.,  links  to  co-orbiting  platform,  free-f lyers, . . . ) . 

6 . 5 . 4 . 1 Core  Realtime  Return  Link 

Data  are  collected  from  subsystems  by  data  acquisition  and  assembled  into 
telemetry  packets  and  packet  segments.  Telemetry  packets  and  return  link 
telecommand  packets  are  interspersed . The  telemetry  packet  and  telecommand 
packets  are  organized  into  telemetry  buffer  units  (TBU's).  TBU 1 s are 
constructed  using  a prioritization  algorithm.  Telecommand  packets  are 
inserted  with  high  priority.  TBU's  are  transmitted  on  a local  bus  to  a set  of 
toggle  buffers  at  the  communication  SSA  return  link  interface  depicted  in 
Figure  6.5—1.  The  TDRSS  SSA  return  link  is  used  for  this  data,  although  it 
may  be  redundantly  transmitted  on  the  KSA  return  link. 

6 . 5 . 4 . 2 Core  Buffered  Return  Link 

The  process  of  storing  and  merging  buffered  data  into  the  return  link  is 
depicted  in  Figure  6.5-2.  The  data  acquisition  function  is  informed  by  the 
communication  subsystem  when  data  must  be  buffered  because  of  communication 
link  dropout  (zone  of  exclusion  or  reconf iguration) . The  buffered  data  is 
stored  on  mass  memory  in  the  TBU  format.  When  the  communication  link  is 
reestablished  the  SSDS' data  acquisition  function  is  informed  by 
communications.  The  location  of  the  buffered  data  is  then  transmitted  to  the 
communications  subsystem.  The  real  time  data  transmission  to  the 
communications  interface  start  again  and  the  communications  subsystem  merges 
the  buffered  TBU's  and  the  realtime  data  on  the  TDRSS  SSA  return  link. 
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Figure  6.5  -1.  Return  Link  for  Core  Realtime  Data 


6-61 


DMS  SW-::| 
(DataAcq,  9ont:£i 
Core  ODB,  « wrr? 
TTC) 


PL  Network  > 


Return 

Comm 

l/F  R-SSA 
— x — (3  Mbps) 


| NIU  | 

NIU 

X. 

T 

SDP 

SDP 

PL/EXP 


PL  PL 

Proc 


DMS 

(Data  Acq, 
PL  ODB, 
TTC) 


Note  1. 

• DMS  Buffers  Data 

• DMS  Informs  Comm  Subsystem  of 
Data  Location 

• Comm  Merges  Buffered  and  Realtime 
Data  By  Fetching  TBU's  From  MM 


R-KSA 
(300  Mbps) 


SW  I 
Cont  L, 


Communications  Subsystem 


Figure  6.5-2.  Return  Link  for  Core  Buffered  Data 
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6 . b . 4 . 3 Payload  Real  Time  Lot*)  Data  Rate  Return  Link  (Figure  6 . 5-3 ) 


Payload  low  data  rate  (defined  currently  as  less  than  10  Mbps)  is  collected  by 
the  SSDS  data  acquisition  function  in  the  P/L  local  area  network  (PLAN).  The 
data  is  received  from  the  P/L's  in  CCSDS  telemetry  packet  format.  Data 
acquisition  builds  TBU's  by  segmenting  long  TLM  packets  and  handles  priority 
access  to  the  telemetry  stream.  Telecommands  are  given  priority  over  data. 

The  TBU's  are  transmitted  on  a parallel  local  bus  to  the  communication 
subsystem  toggle  buffers.  These  TBU's  use  the  KSA  return  link. 

6. 5. 4. 4 Payload  Buffered  Low  Rate  Data  Return  Link  (Figure  6.5-4) 

During  telemetry  link  dropout  payload  low  data  rate  is  buffered  in  mass 
storage  on  the  PLAN.  The  buffered  data  is  then  merged  with  realtime  data  when 
the  KSA  link  is  re-established.  The  merge  is  accomplished  by  the 
communication  subsystem. 

6. 5. 4. 5 Payload  Realtime  High  Data  Rate  Return  Link  (Figure  6.5-5) 

The  P/L  high  data  rate  interface  to  the  SSDS  is  through  a point-to-point  link 
with  the  communication  subsystem.  The  communication  subsystem  merges  high 
rate  data  with  low  data  rate  TBU's  on  the  KSA  link.  This  data  is  in  packet 
telemetry  format  or  it  is  assigned  to  a virtual  channel  by  the  communications 
subsystem. 

6. 5. 4. 6 Payload  Buffered  High  Data  Rate  Return  Link  (Figure  6.5-6) 

During  communication  link  dropout  the  communication  subsystem  buffers  high 
rate  data  on  communication  subsystem  mass  storage.  The  communication 
subsystem  merges  this  data  with  real  time  data  when  the  link  is  reestablished. 

6.5.4. 7 Core  Forward  Link  Telecommands  (Figure  6.5-7) 

Forward  link  telecommands  and  data  are  merged  in  the  TDRSS  SSA  channel.  The 
DMS  telecommand  interface  function  (TLMCMD  I/F)  polls  the  SSA  communications 
forward  link  buffer  on  a parallel  local  bus.  The  buffer  contents  are  examined 
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Figure  6.5-3.  Return  Link  for  PL  Realtime  Low  Data  Rate 
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Figure  6.5-4.  Return  Link  for  PL  Buffered  Low  Data  Rate 
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Figure  6.5  -5.  Return  Link  for  PL  Realtime  High  Data  Rate 
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Communications  Subsystem 


Figure  6.5-6.  Return  Link  for  PL  Buffered  High  Data  Rate 
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Figure  6.5  -7.  Forward  Link  for  Core  Telecommands 


and  disassembled  by  TLMCMD  I/F.  If  the  buffer  contains  data  segments,  those 
data  segments  are  delivered  directly  to  the  destination  mailbox.  (As  an 
example,  a segment  of  a new  program  load  would  be  delivered  to  the  ODBMS  for 
storage  on  mass  memory  and  then  transferred  to  the  targetted  SDP). 

The  KSA  forward  link  is  used  as  a backup  in  the  event  of  SSA  forward  link 
interruption . This  interface  is  also  used  for  growth  in  the  forward  link. 

6. 5. 4. 8 Payload  Telecommands  (Figure  6.5-8) 

Payload  telecommands  are  delivered  through  the  KSA  forward  link  channel.  The 
same  delivery  service  is  provided  by  the  TLMCMD  I/F  function.  The  commands 
are  delivered  to  the  P/L  mailboxes  across  the  core  to  P/L  network  bridge. 

6.5.5  Examples  of  Onboard  Data  Flow 

The  following  sections  describe  selected  examples  to  illustrate  typical 
onboard  SSDS  data  flow  implications. 
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Subsystems 


Figure  6.5-8.  Forward  Link  for  PL  Telecommands 


6.5.5. 1 Payload  without  an  Integrated  SDP. 

In  this  example  the  payload  is  developed  as  a separate  unit  to  be  eventually 
integrated  into  the  SS  with  a standard  subsystem  data  processor  (SDP).  The 
scenario  developed  herein  is  for  the  case  of  a very  low  data  rate  experiment 
(under  10  Kbps),  one  relatively  simple  so  that  requirements  for  onboard  crew 
resources  (after  installation)  would  not  be  required  for  interactive  control 
or  maintenance  operations.  The  payload  is  a university  developed  experiment 
and  the  interfaces  selected  are  based  on  minimal  use  of  SSDS  resources  (i.e. 
graduate  students  would  be  available  to  develop  the  payload,  its  interfaces 
and  facilities  to  support  its  operation). 

In  this  case,  the  customer's  payload  operation  facility  is  on  campus  and  his 
interface  with  the  SSDS  will  be  via  CCSDS  TM/TC  packets.  SDP  application 
programs  that  control  his  payload,  and  certain  ground  facilities  will  also  be 
required . 
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After  examining  the  standard  SSDS  onboard  SDP  I/O  interfaces  available,  this 
customer  has  elected  to  use  a serial,  EIA  RS422,  synchronous  I/F  since  this 
requires  the  least  hardware  and  easily  satisfies  his  data  rate.  He  has 
analyzed  the  control  and  data  flow  involved  and  has  concluded  that  a personal 
computer  (PC)  will  satisfy  his  Control  Center  workstation  and  quick  look  data 
processing  requirements  and  that  a mainframe— to— PC  interface  will  satisfy  his 
production  data  processing  and  archive  requirements . 

Based  on  the  above  and  on  discussions  with  the  SS  program  office,  his 
perspective  of  his  interface  with  the  SSDS  and  with  his  payload  will  be  as 
shown  in  Figure  6.5-9. 

He  will  have  electronic  interfaces  with  his  payload  via  TM/TC  packets,  with 
the  OMCC  for  schedule  development  and  operations,  and  with  the  EDC  (if 
required)  for  acquiring  additional  ancillary  data  beyond  that  obtained  onboard 
at  the  time  of  original  payload  operations.  Voice  interfaces  with  the  OMCC 
and  for  conferencing  with  the  SS  crew  are  also  provided. 


Figure  6.5-9.  Payload  Operations  - Customer  Perspective  (Example)  . 
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The  payload  will  be  approximately  25  meters  from  the  IMIU/SDP  node  and  will  be 
connected  using  three  shielded  twisted  wire-pairs.  Power  and  ICS  interfaces 
will  also  be  supplied  as  shown. 


The  protocols  that  the  customer  will  be  involved  with  are  those  shown  in 
Figure  6.5-10.  The  CCSDS  protocols  for  TM  and  TC  are  discussed  in  depth  in 
Section  4 and  are  only  summarized  in  the  figure  (note  that  a specific 
Application  Process  ID  number  has  been  assigned).  The  RS  422  interface  is 
serial  with  8 bit  characters  (octets)  and  the  customer  will  develop  his  own 
data  field  assignments  for  command  and  data  (see  examples).  His  other 
electronic  interfaces  with  the  EDO  and  OMCC  will  use  a standard  ASCII, 
asynchronous  protocols,  a 300—2400  Baud  modem,  and  a dial-up  telephone. 


Figure  6.5-10.  Protocols  in  Payload  Operations 
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The  real  physical  communication  network  that  the  customer  does  not  see 
(transparent)  is  illustrated  in  Figure  6.5-11.  In  this  example,  his  link  with 
the  Data  Handling  Center  (DHC)  at  White  Sands  will  be  via  public 
circuit-switched  and  packet-switched  networks,  as  shown.  His  TM/TC  packets 
are  transmitted  through  space  and  routed  at  the  DHC  and  the  onboard  C&T  node 
as  was  described  previously  in  Section  4.  Onboard,  ISO  layers  2 and  3 provide 
routing  information  for  transport  to  the  final  destination  IMIU  and  the  upper 
ISO  layers  in  the  SDP  recover  the  TM/TC  packets  resulting  in  the  peer-to-peer 
TM/TC  communications  shown  in  the  figure.  On  the  return  link  the  customer 
data  is  separated  from  other  downlink  data  at  the  DHC  and  routed  to  his 
control  center  where  all  of  his  data  processing  is  done.  Packets  may  not 
arrive  in  the  correct  sequence,  but  can  be  readily  reordered  using  packet 
headers . 

To  implement  the  operations  described  above,  the  customer  will  supply  the 
control  center,  the  onboard  payload  and  interface  harness,  and  in  addition,  he 
will  reserve  and  provide  the  onboard  resources  shown  in  Figure  6.5-12. 
Engineering  or  ancillary  data  will  be  provided  through  a real  time  interface 
with  the  core  DMS  or  retrieved  from  the  EDC  as  required. 


CUSTOMER  OPERATIONS 


A scenario  for  customer  operation  will  now  be  described  for  this  customer  and 
his  payload  and  using  the  protocols  described,  and  the  interfaces  shown  in 
Figure  6.5-9  thru  -12.  In  this  case  the  customer  is  requesting  a session 
which  is  not  currently  scheduled  (his  payload  is  currently  powered  OFF) 
because  a scientific  event-of-opportunity  has  just  presented  itself  that  he 
would  like  to  capture  via  his  payload  sensor.  This  scenario  will  involve  only 
electronic  data  exchanges  with  the  SSIS/SSDS,  no  voice  exchanges  will  be 
required  (since  no  anomolies  occur).  Additionally,  the  customer  is  providing 
his  own  data  link  to  the  DHC  which  is  not  implemented  with  the  full  seven 
layer  ISO  model.  It  includes  a two-layer  interface  through  the  circuit 
switched  network  (to  the  TYMNET  PAD)  and  a three-layer  interface  through 
TYMNET’S  public  packet  switched  network  (i.e.,  he  is  not  willing  to  pay  the 
cost  for  full  ISO/OSI  services).  He  is  implementing  a message  passing  service 
at  the  Application  layer,  he  will  not  have  Session  services  to  recover  data  in 
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the  event  of  a disorderly  disconnect  to/from  White  Sands,  and  he  will  not  have 
end-to-end  error  protection  (to/from  White  Sands)  via  Transport  layer 
services.  To  provide  for  a degree  of  error  protection,  his  payload  software 
in  the  SDP  that  packages  the  payload  data  will  compute  a module  2^  check 
sum  and  insert  the  result  into  the  optional  Packet  Error  Control  field  in  the 
CCSDS  TM  packet  (see  Figure  6.5-10).  Highlights  of  this  sequence  are 
presented  in  Table  6.5-1. 


TABLE  6.5-1  - CUSTOMER  OPERATIONS 


Negotiate  For  Non-Scheduled  Services 


1.  The  customer's  PC  autodials  via  public  telephone  to  OMCC,  prompt 
appears  on  PC  screen  to  LOG  ON,  provide  ID,  and  then  provide 
PASSWORO.  OMCC  authenticates  customer. 

2.  Service  menu  appears  on  screen  to  select  option: 

1 . Display  Schedule 

2.  Request  Schedule 

3.  ... 

3.  Customer  selects  option  2 and  via  keyboard  display,  menus, 
prompts,  HELP, .. .negotiates  a schedule  to  start  In  six  minutes 
and  to  terminate  after  a 2.55  hour  session.  He  Is  Informed  that 
there  will  be  a ZOE  outage,  but  that  his  data  will  be  stored  In 
an  onboard  file  which  he  can  request  to  be  downlinked  at  his 
convenience.  (The  file  will  be  sequential,  time  stamped  CCSDS 
TM  packets.) 

4.  Customer  LOGS  OFF  from  GSC 

Payload  Session  Establishment 

i 

5.  Customer  has  a TYMNET  service  to  White  Sands/DHC  which  he 
assesses  via  local  public  circuit  switched  network.  (NOTE: 

TYMNET  Is  a public  packet  switched  network  providing  three  layer 
data  delivery  services  and  basically  charging  on  a per  packet 
basis) . 

6.  Prompt  appears  Indicating  that  he  Is  connected  to  White 
Sands/DHC. 


7.  He  now  repeats  LOG  ON,  ID,  and  PASSWORD  sequence  for  DHC 
authentication. 
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TABLE  6.5-1  - CUSTOMER  OPERATIONS  (Continued) 


8.  Menu  options  for  services  are  displayed  and  the  customer 
responds  that  he  wants  his  payload  activated.  He  Is  Informed 
that  his  session  Is  scheduled  with  no  delays  and  will  be 
activated  In  4.00  minutes,  and  to  standby  to  Initiate  operations. 

9.  A countdown  clock  Is  displayed  and  the  payload  activation 
sequence  Is  presented  followed  by  a message  that  the  network 
manager  has  attached  his  payload  to  the  network  and  he  can  now 
communicate  with  his  payload. 

10.  The  customer  now  Initiates  his  local  communication  and  control 
program  which  generate  TC  packets  for  the  following  commands 
that  are  transported  to  his  payload. 

o Bidirectional  communication  test 
o Program  load  from  onboard  mass  store 
o Payload  self  test 

o Sensor  activation  and  TM  packet  delivery  to  CC 

11.  He  will  now  go  through  the  following  sequence  In  his  control 
center: 

o Quick  look  data  with  window  for  display  of  sensor 
performance 

data  (engineering  units  and  graphic  displays), 
o Initiate  storage  of  production  data  on  local  disk  store 
o Monitors  production  data  and  performance  data  for 
duration  of 
session 

12.  As  his  session  nears  Its  scheduled  completion  a window  will 
appear  on  his  screen  Indicating  that  a message  (TM  packet)  has 
been  received  from  the  resource  manager  that  he  will  be 
disconnected  In  3.00  minutes  and  that  he  should  secure  his 
payload  for  an  orderly  shutdown.  He  does  so  via  TC  packet,  LOGS 
OFF  from  the  DHC  and  disconnects  from  TYMNET  and  the  local 
telephone  company. 

13.  Via  his  mainframe  Interface,  he  transmits  the  production  data 
files  for  processing  and  archiving  on  magnetic  tape.  Mainframe 
processing  provides  him  with  his  desired  output  In  his  selected 
format. 
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6. 5. 5. 2 Payload  with  an  Integrated  SDP 


Onboard  operations  with  an  integrated  SDP/payload  showing  data  flow  from  the 
payload  to  the  C&T  node  were  discussed  in  section  4.3.2  for  a hypothetical 
payload,  COM  XXXX. 


In  this  example,  the  customer  has  a more  sophisticated  payload  than  in  the 
previous  case  and  has  developed  his  own  package  incorporating  SSDS  standard 
circuits  and  his  own  unique  I/O  interface  circuits.  The  payload  is  normally 
powered  OFF  and  the  scenario  described  in  Section  4 discussed  the 
initialization  and  session  establishment  sequence. 

6. 5. 5. 3 Onboard  Inter-Subsystem  Data  Flow 

A generic  model  (example)  for  inter-subsystem  data  flow  is  shown  in  Figure 
6.5-13  in  terms  of  an  SSDS  subsystem  interface.  In  order  to  simplify  the 
intent  of  the  discussion  in  this  paragraph,  the  SSDS  side  is  shown  without  any 
replications  for  fault  tolerance  considerations. 

On  the  SSDS  side  shown  in  the  figure,  three  different  configurations  of  an 
NIU,  I/O  Controller  and  SDP  are  shown;  in  all  cases  the  DOS  is  distributed 
between  the  NIU  (layers  1-4)  and  the  I/O  Controller  or  SDP  (layers  5-7). 

Implicitly,  at  least  two  configurations  of  the  I/O  Controller  will  exist  and, 
in  fact,  multiple  versions  will  exist  to  facilitate  the  various  backend 
standard  I/O  interfaces  described  elsewhere  in  this  document. 

The  equivalent  of  an  ICO  between  the  SSDS  and  the  subsystem  would  be  embodied 
in  the  requirements  that  specify  (in  this  example)  a MIL-STD-1553B  interface 
for  the  physical  and  data  link  layers  (equivalent  to  layers  1 and  2 in  the  OSI 
model)  and  at  the  application  layer,  the  message  configurations  for  the  32 
word  (16  bits/word)  Control  Frame  and  Data  Frame.  These  frames  would  be 
defined  to  specify  the  formats  that  receive  sensor  data  values  and  those  that 
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transmit  effector  or  output  values.  These  formats  would  also  be  specified  for 
various  modes  of  operation  in  which  the  subsystem  would  be  required  to 
operate.  Different  modes  (various  operational,  test,  maintenance,  etc.)  would 
require,  in  general,  different  measurement  data  sets  and  with  various 
measurement  (update)  frequencies. 
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CASE  1:  INTRA LAN 


For  this  first  case,  (Figure  6.5-13)  k nodes  (k  = 32  max)  would  be  distributed 
throughout  a region  acquiring  sensory  data  and  responding  to  effector  output 
commands.  Each  node,  as  shown,  would  include  a controller  and  power  supply 
and  various  combinations  of  data  acquisition  and  data  output  circuits  (e.g., 
A/D  converter,  multiplexers,  amplifiers  of  various  types,  signal  conditioning, 
etc . ) . 

By  way  of  review,  MIL-STD-1553B  is  implemented  with  twisted  shielded  wire 
pairs  (TSWP),  is  transformer  coupled  at  every  node,  and  has  a data 
transmission  rate  of  1 Mbps.  The  logical  link  control  (LLC)  sublayer 
specifies  a polling  procedure  between  a single  master  and  multiple  secondary 
stations.  Control  frames  are  sent  from  the  primary  or  master,  and  data  frames 
are  received  from  the  secondary  nodes. 

CASE  2 : INTER-LAN 


The  case  considered  now  is  for  a distributed  subsystem,  one  where  sensors  and 
effectors  are  distributed  throughout  a module  and  between  modules.  In  the 
example  developed  here,  data  acquisition  from  these  distributed  sensors  is 
implemented  as  shown  in  Figure  6.5-14  using  various  standard  I/O  interfaces  as 
required  by  the  application.  Likewise,  the  effector  values  computed  in  the 
SDP  would  be  transmitted  using  the  same  I/O  capabilities. 

The  application  program  in  this  example  is  shown  to  be  resident  in  only  one 
SDP,  but  with  distributed  data  sources  and  sinks  interconnected  locally  via 
standard  backend  interfaces  and  throughout  the  SS  via  the  LANs  interconnected 
by  bridges.  Interprocess  message  transfer  via  the  LAN  utilizes  the  layer  3 

s 

NOS  services  described  earlier. 
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Application  Programs  Shown  in  One 
SDP  but  Could  be  Distributed  to 
More  than  One  and  Could  be  Relocated 
to  Other  SDPs  Based  on  Safe  Haven 
Contingencies  and  Considerations 
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Figure  6.5-14.  Distributed  Subsystem  Data  Flow 


6.6  Onboard  SSDS  Architecture 


6.6.1  Distribution  of  Processing 

The  distribution  of  processing  into  the  onboard  SSDS  is  based  on  traditional 
subdivisions  of  spacecraft  functions,  function  sizing  estimates,  function 
criticality  and  fault  tolerance  requirements,  interfunction  communication, 
safe  haven  requirements,  minimization  of  DMS  elements,  and  the  desire  for 
subsystem  autonomy.  The  memory  configurations  and  their  respective 
distribution  are  presented  in  Table  6.6—1.  The  total  network  that  supports 
this  distribution  is  shown  in  Figure  6.6-1  and  Figure  6.6-2.  The  PL/EXP  and 
core  functions  are  separated  to  insure  the  highest  degree  of  traffic  isolation 
and,  therefore,  functional  autonomy. 

The  architecture  selected  is  based  on  derived  requirements  for  growth, 
functional  subsystem  autonomy,  the  build-up  of  functionality,  and  the 
flexibility  to  select  fault  tolerant  options. 

The  main  features  of  the  architecture  are:  (1)  the  ability  of  any  SDP  to 

assume  any  memory  configuration  (one  or  more  subsystems  allocated  to  an  SDP 
memory  load);  (2)  a single  high-speed,  DMA  interface  between  the  SDP  arid  NIU; 
(3)  the  incorporation  of  the  standard,  traditional  I/O  functions  between 
computers  and  sensors  and  effectors  into  the  NIU  (which  makes  possible  feature 
1;  (4)  the  workstation  as  a computing  element  with  potentially  the  same  power 
as  the  SDP  plus  user  interface  capability  so  resources  can  be  shared  for 
infrequent  interactive  tasks. 

Processor  fault  tolerance  is  accomplished  by  a system  service  function  which 
detects  failures  and  initiates  fault  down  to  preferred  spares.  NIU  failures 
do  not  require  memory  reconf igurations  since  the  programs  are  the  same  for  any 
triad  group.  Only  port  moding  is  required  or  reassignment  by  the  network 
manager  (this  reassignment  accomplishes  changes  in  routing  which  are  then 
static  - no  dynamic  routing).  For  failure  detection  the  SDP  and  NIU  are 
considered  a node. 
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Figure  6.6-1.  Processing  Distribution  for  Core  LAN 
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The  SDP  sparing  strategy  is  presented  in  Table  6.6-1.  Spare  computers  within 
a triad  are  preferred  as  backups  for  failures  in  the  triad  but  safe  haven 
requirements  make  it  necessary  to  be  able  to  transfer  memory  configurations  to 
another  physical  module.  This  is  the  case  for  all  the  SDP's  except  those  on 
the  transverse  boom  which  only  have  spares  within  the  local  triad.  These  are 
called  preferred  spares  for  the  following  reason:  even  though  it  is  possible 

to  use  a member  of  these  triads  for  some  other  memory  configuration  for  some 
period  of  time,  if  several  failures  occur  in  this  triad  then  the  "visiting" 
memory  configuration  is  bumped  to  another  SDP  (or  a degraded  mode  occurs 
because  no  spares  are  available). 

The  triad  in  HM1  operates  in  a "shared  spare"  mode.  In  other  words  the 
preferred  spare  is  the  spare  in  the  local  triad  but  this  is  shared  by  the  two 
memory  configurations  (memory  configurations  3 and  4)  active  in  the  HM1  triad 
1.  Additional  spares  are  located  in  the  HM2  triad  1.  Safe  haven  requirements 
are  met  in  this  sparing  strategy.  The  HM2  triad  1 uses  the  local  spares  as 
the  preferred  spares  for  memory  configuration  5 but  resorts  to  the  HM1  triad 
for  safe  haven  backup. 

With  this  architecture  it  is  possible  to  absorb  growth  by  having  a currently 
inactive  triad  member  become  active  and  at  the  same  time  introduce  a SDP  into 
a "spare  pool"  on  the  core  network. 

The  preferred  spare  strategy  used  for  the  transverse  boom  triad  1 also  results 
in  deterministic  I/O  timing,  a requirement  for  the  hard  real-time  functions 
such  as  attitude  control.  Predictability  in  I/O  delays  comes  from  the  fact 
that  traffic  to  the  local  bus  is  on  a string  which  is  not  shared  with  any 
other  functions  even  if  a "visiting"  memory  configuration  is  executing  in  this 
triad  (i.e.,  no  traffic  interference  occurs  in  the  NIU  because  traffic  only 
couples  when  reaching  the  core  network). 

The  SDP  memory  configurations  are  described  in  Table  6.6-2.  These  memory 
configurations  are  distributed  into  a total  network  of  16  SDP's.  Six 
workstations  and  38  NIU 1 s are  also  provided.  The  memory  configuration  for  the 
workstations  is  described  in  Table  6.6-3.  The  core  and  P/L  network  contain  12 
bridges.  Each  bridge  has  the  same  software  which  includes  layers  1 4 of  DOS 
(See  section  6.4.2). 
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Table  6.6-2 
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Table  6.6-3 
WORKSTATION 

MEMORY  CONFIGURATIONS  (IOC) 
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It  should  be  noted  that  the  term  "memory  configuration"  mentioned  above 
implies  an  SDP  memory  load  containing  the  application  software  for  one  or  more 
subsystems.  The  decision  to  combine  subsystem  application  software  into 
memory  configurations  was  motivated  by  the  following  considerations: 

• Desire  to  minimize  the  total  number  of  SDP's  and  NIU's  required. 

This  reduces  program  costs,  power/cooling  resource  demands  and 
network  complexity. 

• Group  together  subsystem  application  software  with  high  data  exchange 
requirements . 

• Group  together  subsystem  application  software  which  must  be  relocated 
to  address  safe  haven  requirement. 

The  ability  of  a subsystem  contractor  to  design  and  checkout  his  subsystem 
without  significant  interface  to  a central  integration  facility  can  still  be 
accomplished.  A functional  equivalent  of  the  SDP/NIU  and  appropriate  data  bus 
interface  simulator  can  be  used  in  a standalone  test  verification  mode.  With 
a standard  DOS  the  linkage  of  subsystem  applications  software  within  an  SDP 
should  be  (largely)  transparent. 

6.6.1. 1 Data  Management  Subsystem  (Figure  6.6-3) 

The  DMS  "application"  functions  are  resident  in  two  SDP's;  SDP4  and  SDP8. 

SDP4  is  backed  up  by  SDP5  and  SDP6  in  the  transverse  boom  triad  1.  SDP8  is 
backed  up  by  SDP9  in  HM1  and  SDP12  in  HM2.  SDP4  nominally  contains  memory 
configuration  2 which  performs  the  functions  required  to  interface  to  the 
communication  subsystem  for  the  return  and  forward  SSA  link.  Time  management 
is  also  contained  in  memory  configuration  2.  The  master  timing  units  (MTU's) 
used  by  SDP4  are  attached  to  a local  bus.  When  the  GPS  receivers  are  added  to 
the  upper  boom,  time  management  can  use  the  time  reference  provided  by  GPS  as 
an  addition  reference  source. 


6-86 


Habitat  Module  1 


Figure  6.6-3.  Data  Management  Subsystem 


The  DMS  operational  data  base  (ODB)  is  nominally  resident  in  SDP8  (memory 
configuration  4).  The  mass  storage  is  distributed  in  HM1,  HM2  and  LAB2 . The 
DMS  stores  telemetry  data  on  mass  storage  during  return  link  dropout.  After 
the  return  link  has  been  restored  the  DMS  allows  the  communication  subsystem 
to  retrieve  this  buffered  data  from  mass  storage  for  merging  with  realtime 
data. 

For  illustration  purposes,-  the  DMS  can  be  reconfigured  as  shown  in  Figure 
6.6-3  using  the  work  stations  resident  in  HM1 . This  control  location  is 
illustrated  in  many  subsequent  figures.  However,  any  workstation  can  be 
configured  to  control  any  subsystem.  Other  workstations  locations  are  shown 
in  Figures  6.6-1  and  6.6-2.  Menu  panels  are  presented  at  all  active  work 
stations.  These  panels  allow  the  work  station  to  be  configured  by  crew 
selection.  Programs  are  then  loaded  in  the  work  station  which  supports 
interaction  with  the  crew  for  DMS  status  and  reconf iguration . 

6. 6. 1.2  Communication  Subsystem  (Figure  6.6-4) 

The  communication  subsystem  is  resident  in  SDP4  (memory  configuration  2)  and 
backed  up  by  SDP5  and  SDP6  in  the  transverse  boom  triad  1.  Telemetry  for  the 
SSA  return  link  is  transmitted  in  packet  telemetry  format  on  a local  bus  to 
the  communication  toggle  buffers.  Telecommands  are  also  received  on  this 
local  bus  by  a polling  process.  The  forward  SSA  link  buffer  is  polled  by 
transferring  the  communication  interface  buffer  to  SDP4.  Packet  segments  in 
the  forward  link  buffers  are  then  disassembled  and  transported  to  the  onboard 
destination  task. 

Reconfiguration  of  the  communication  subsystem  is  through  programs  loaded  into 
any  of  the  core  workstations  (similar  to  description  in  6.6.1).  This 
reconf iguration  process  is  highly  automated  with  (mostly)  optional  crew 
interaction . 
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6.6. 1.3  ftttitude  Control  (Figure  6,6-5) 


Attitude  control  is  nominally  resident  in  SDP1  (memory  configuration  1)  and 
backed  up  by  SDP2  and  SDP3 . All  of  these  computers  are  in  transverse  boom 
triad  1.  Attitude  determination  is  generally  considered  to  be  a navigation 
function,  but  is  embedded  within  attitude  control  for  this  description. 
Communication  with  the  CMG's,  strap-down  assemblies,  star  trackers  and  solar- 
panel  activators  is  through  a local  bus  on  the  transverse  boom  triad  1.  When 
the  solar  panel  extensions  and  magnetic  torquers  are  added  they  also  use  the 
same  local  bus  for  communication.  The  RCS  is  distributed  along  the  lower  keel 
and  lower  keel  extension.  NIU7,  NIU8  and  NIU9  located  on  the  lower  keel  are 
used  to  communicate  from  the  transverse  boom  triad  1 to  the  RCS  on  a local  bus. 

The  user  interface  to  the  attitude  control  function  is  via  the  core 
workstation  shared  resources  as  described  previously. 

6.6. 1.4  Tracking  Subsystem  (Figure  6.6-6) 

The  tracking  subsystem  resides  in  memory  configuration  1 which  is  nominally 
assigned  to  SDP1  and  backed  up  by  SDP2  and  SDP3  on  the  transverse  boom.  The 
tracking  function  collects  data  from  various  transponders  and  radars 
distributed  on  the  upper  boom  and  also  proximity  trackers  on  HMl  and  HM2 . 

This  data  is  conditioned  and  transmitted  to  navigation  and  traffic  control 
functions . 

6.6. 1.5  IMaviqation  (Figure  6.6-7) 

The  navigation  function  is  contained  in  memory  configuration  1 which  is 
resident  in  SDP1  and  has  preferred  backups  in  SDP2  and  SDP3 . The  navigation 
function  receives  GPS  data  from  instrumentation  on  the  upper  boom.  TORS 
tracking  data  is  also  received  from  the  TDRS  S-band  transponder  on  the 
transverse  boom  (this  function  may  migrate  to  the  upper  boom).  User  interface 
to  the  navigation  function  is  through  any  of  the  core  workstations  as 
described  previously. 
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Habitat  Module  1 


Figure  6.6-6.  Tracking  Subsystem 


Habitat  Module  1 
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Figure  6.6-7.  Navigation 


6. 6. 1.6  Electrical  Power  Subsystem  (Figure  6.6-8) 


The  electrical  power  subsystem  is  contained  in  memory  configuration  2 and 
resident  in  SDP4  with  preferred  spares  SDP5  and  SDP6 . Electrical  power 
sensors  and  effectors  are  distributed  on  the  truss  and  within  the  pressurized 
modules.  The  local  buses  and  associated  IMIU's  are  shown  in  Figure  6.6-8.  The 
WIU's  within  HM2  also  have  a connector  on  the  local  bus  for  the  logistics 
module . 

6. 6. 1.7  Thermal  Control  Subsystem  (Figure  6.6-9) 

The  thermal  control  subsystem  is  contained  in  memory  configuration  2 and 
resides  in  SDP4  with  preferred  backups  SDP5  and  SDP6 . Thermal  control  is 
distributed  on  the  truss  and  in  the  pressurized  modules.  This  subsystem 
shares  local  buses  with  the  electrical  power  subsystem  since  these  subsystems 
are  similarly  distributed.  The  local  bus  on  the  IMIU's  in  HM2  have  a connector 
to  the  logistics  module  in  the  event  thermal  control  is  required  in  this 
module . 

6.6. 1.8  Environmental  Control  and  Life  Support  Subsystem  (Figure  6.6-10) 

ECLSS  is  contained  in  memory  configuration  3 and  resides  in  SDP7  (HM1  triad  1) 
with  a local  preferred  spare  (SDP9)  and  safe  haven  spare  SDP11  in  HM2  triad 
1.  The  ECLSS  sensors  and  effectors  are  distributed  in  the  pressurized  modules 
and  share  local  buses  with  power  and  thermal  subsystems.  The  preferred  spare 
in  the  HM1  traid  1 is  shared  with  memory  configuration  4.  Communication  with 
the  logistics  module  can  be  on  a local  bus  connected  to  the  HM2  local  bus. 


6. 6. 1.9  Traffic  Control  (Figure  6.6-11) 

The  traffic  control  function  is  contained  in  memory  configuration  1 and 
resides  in  SDP1  and  is  backed  up  by  preferred  spares  SDP2  and  SDP3  . Traffic 
control  has  no  sensors  or  effectors  but  inputs  from  other  subsystems  and  sends 
commands  to  those  subsystems  on  the  core  network.  User  interface  is  through 
any  of  the  core  workstations. 


6-94 


Habitat  Module  1 


Figure  6.6-8.  Electrical  Power  Subsystem 
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Figure  6.6-9.  Thermal  Control  Subsystem 


1 


Figure  6.6-10.  Environmental  Control  and  Life  Support  Subsystem 


Figure  6.6-11.  Traffic  Control 
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The  facility  management  subsystem  is  contained  in  memory  configuration  4 and 
resides  in  SDP8  with  preferred  backup  SDP9  and  safe  haven  backup  in  SDP12  (HM2 
triad  1).  Facility  management  has  no  sensors  or  effectors  but  receives  inputs 
from  other  subsystems  and  sends  commands  to  those  subsystems  on  the  core 
network.  User  interface  is  through  any  of  the  core  workstations. 


6.6.1.11  Structures  and  Mechanisms  Subsystem  (Figure  6.6--13) 


The  structures  and  mechanisms  subsystem  is  contained  in  memory  configuration  3 
and  resides  in  SDP7  of  HMl  triad  1.  The  preferred  backup  spare  is  SDP9  and 
the  safe  haven  backup  is  SDP11  in  HM2  triad  1.  This  subsystem  has  alignment 
and  mode  sensors  distributed  on  the  truss  and  modules. 


•Backup 


Figure  6.6-12.  Facility  Management  Subsystem 
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Figure  6.6-13.  Structures/Mechanisms  Subsystems 


Interface  to  the  airlock  modules  is  across  local  bus  connectors  from  the  l-IMl 
and  HM2  modules.  The  control  of  the  MRMS  is  through  telecommands  transmitted 
to  the  communications  system  interface.  User  interface  is  through  any  of  the 
core  workstations.  Manual  control  of  the  MRMS  is  through  the  fixed 
workstation  which  is  configured  for  MRMS  manual  inputs. 

6.6.1.12  Crew  Systems/Subsystems  (Figure  6.6-14) 

The  crew  systems  subsystem  is  contained  in  memory  configuration  3 and  resides 
in  SDP7  of  HM1  triad  1.  The  preferred  backup  is  SDP9  (also  in  HM1  triad  1) 
and  safe  haven  backup  SOPH  in  HM2  triad  1.  Crew  system  sensors  and  effectors 
are  distributed  in  HM1  and  MM2.  User  interface  is  through  any  of  the  core 
workstations . 


6.6.1.13  Payload  Support  (Figure  6.6-15) 

The  PL  support  for  return  link  telemetry  and  data  base  services  are  contained 
in  memory  configuration  8 which  is  resident  in  SDP15  (LAB2)  with  backup  SDP16 
(LABI).  SDP15  interfaces  with  PL  mass  storage  devices  and  the  communication 
interface  to  provide  the  return  link  telemetry  service.  Buffering  is 
accomplished  on  the  PL  mass  storage.  Forward  link  PL  services  originate  in 
the  core  network  in  SDP4  (memory  configuration  2).  The  telecommand  interface 
service  delivers  telecommands  to  destination  tasks  in  the  PL  network  across  a 
bridge. 

PL  programs  can  be  uploaded  to  the  mass  storage  devices  and  execution 
initiated  in  SDP13  and  14  in  LAB2  and  SDP16  in  LABI.  A PL  workstation  is  also 
provided  in  LABI.  Communication  with  earth  viewing  experiments  is 
accomplished  using  IMIU  36,  37,  38  on  the  earth  viewing  pallet.  Communication 
with  upper  boom  experiments  is  through  IMIU  22,  23,  24.  Experiments  internal 
to  the  lab  modules  communicate  using  IMIU  28,  29,  30,  31  and  32. 

Ancillary  data  can  be  obtained  by  communicating  with  the  core  operational  data 
base  across  the  bridge. 
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Figure  6.6-14  Crew  Systems  Subsystem 
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Network  Architecture 


6.6.2. 1 Topology 

t 

The  "strawman"  onboard  local  area  network  configuration  consists  of  two  major 
network  partitions  isolating  PL/EXP  traffic  from  core  traffic.  There  is  a 
bridge  between  the  network  partitions  to  support  core  and  PL/EXP  data 
exchange.  Ancillary  data  and  forward  link  telemetry  flow  from  the  core 
network  to  the  PL/EXP  network  across  the  bridge.  The  topology  of  the  network 
is  a group  of  interconnected  dual  redundant  token  rings  each  with  a multi-port 
ring  concentrator.  The  physical  distribution  of  the  network  elements  is  shown 
in  Figure  6.6-16.  The  network  topology  is  shown  in  Figure  6.6-17  a and  b. 

Dual  redundancy  exists  in  the  bridges,  ring  concentrators  and  optic- to-optic 
connectors . 

6. 6. 2. 2 Access  Protocol 

A separate  token  circulates  in  each  ring.  A bypass  capability  is  provided  at 
the  ring  concentrator  for  inactive  or  failed  ports.  Port  moding  allows 
individual  ring  ports  to  switch  between  the  two  redundant  rings. 


The  network  access  is  through  a priority  token  circulating  within  each  ring. 
The  message  priority  is  assigned  to  periodic  traffic  on  a rate  monotonic  basis 
(higher  rate  has  higher  priority) . Aperiodic  traffic  has  lowest  priority. 

6. 6. 2. 3  Network  Operating  System  (NOS) 

The  NOS  supports  the  interface  to  the  network  for  object  oriented  task-to-task 
message  passing.  It  is  a subset  of  the  overall  onboard  Distributed  Operating 
System  (DOS)  described  in  section  6.4.4  and  consists  of  the  functions 
corresponding  to  layers  1 through  4 of  the  ISO/OSI  model.  The  NOS  resides  in 
the  NIU’s.  A brief  summary  of  the  applicable  functions  in  these  layers  is 
shown  below  in  tabular  form. 
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Figure  6.6-16.  Network  Physical  Distribution 
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Figure  6.6-  17A.  Network  Topology  Backbone 
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1 . PHYSICAL  LAYER 

- Handles  voltages  and  electrical  pulses 

- Handles  cables,  connectors,  and  components  (interfaces  to  media) 

- Handles  collision  detection  for  CSMA/CD  access  method 

2.  DATA-LINK  LAYER 

- Reliable  transfer  of  data  across  a single  link 

- Adds  flags  to  indicate  beginnings  and  ends  of  messages 

- Adds  error-checking  algorithms  (CRC,  ...) 

- Makes  sure  data  are  not  mistaken  for  flags  (transparency  mechanism) 

- Provides  access  methods  for  local-area  networks 

3 .  NETWORK  LAYER 

- Sets  up  routes  for  packets  to  travel 

— Addresses  network  modes  on  the  route  through  which  the  packets  travel 

- May  disassemble  transport  messages  into  packets  and  reassemble  them 
at  the  destination. 

— Sends  control  messages  to  peer  layers  about  own  status 

- Congestion  control  (regulates  flooding  within  the  network) 

— Recognizes  message  priorities  and  sends  messages  in  proper  order 

- Internetworking  (both  connection-oriented  and  connectionless) 


4.  TRANSPORT  LAYER 

- Reliable  end-to-end  data  transfer  (connection  service) 

- Multiplex  end-user  addresses  onto  network 

- End-to-end  error  detection  and  recovery 

- Flow  control 

- Monitoring  quality  of  service 

- Possibly  disassemblies  and  reassembles  session  messages 
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6.6.3  Major  Architecture  Issue 


One  major  feature  of  the  presented  strawman  architecture  needs  special 
discussion.  In  the  strawman  architecture  it  is  possible  to  communicate  with 
any  NIU  local  bus  from  any  SDP  on  the  network.  The  reference  configuration 
does  not  allow  access  to  all  the  local  buses  from  any  SDP.  Some  SDP's  have 
dedicated  local  buses  that  are  controlled  by  that  SDP.  The  flow  of 
communication  in  the  strawman  architecture  is  shown  in  Figure  6.6-18a  and  the 
reference  configuration  is  shown  in  Figure  6.6-18b. 

In  both  the  strawman  architecture  and  reference  configuration  architecture  the 
interface  between  NIU  and  SDP  is  similar.  Both  architectures  also  have  an 
interface  to  local  buses  through  ports  on  the  back-end  of  the  l\IIU.  This  is 
for  sensor  and  effector  (S&E)  communication .The  I/O  programs  to  accomplish 
this  S&E  I/O  must  reside  in  the  NIU  and  these  programs  are  unique  to  Ihe 
configuration  of  the  back-end  S&E  configuration. 

The  key  differences  in  the  architectures  are  in  the  way  local  buses  are 
communicated  with  when  the  NIU  and  SDP  are  co-located . The  ref.  config. 
allows  for  a sensor  and  effector  (S&E)  interface  to  the  SDP.  This  means  that 
only  this  class  of  SDP  can  be  used  to  perform  the  functions  associated  with 
the  S&E  attached  to  the  SDP  local  buses.  No  other  SDP's  can  backup  this 
function  in  case  of  failure  because  communication  is  through  the  failed  SDP. 

The  spare  SDP's  with  S&E  interface  back-ends  still  could  be  used  for  other 
functions  only  requiring  communication  via  the  network. 

The  strawman  architecture  has  no  S&E  interface  to  the  SDP.  The  strawman 
architecture  has  a configuration  with  both  an  SDP  and  local  bus  on  the  same 
NIU  back-end  to  accomplish  a measure  of  commonality  for  SDP's. 


In  Figure  6.6-18a,  the  configuration  with  an  SDP  and  local  bus  on  the  NIU 
back-end  is  shown.  If  the  co-located  SDP's  request  data  from  the  local  bus, 
the  communication  must  be  through  the  NIU.  The  SDP  does  not  know  if  the  S&E's 
are  co-located  or  remotely  distributed  on  some  other  NIU  back-end.  The  local 
NIU  knows  that  the  S&E  I/O  programs  being  addressed  by  the  SDP  are  co-located 
and  does  not  use  the  layered  protocol  (i.e.,  network  communication)  but  just 


6-109 


Figure  6.6-1 8a.  N1U  Alternative  1 (Recommended  Architecture) 


Figure  6.6>18b.  NIU  Alternative  2 (Ref  Configuration) 
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triggers  the  local  I/O  programs  directly.  This  architecture  allows  any  SOP  in 
the  network  to  assume  any  function,  a powerful  option  when  dealing  with  fault 
tolerant  strategies. 

The  hardware  to  accomplish  either  architecture  is  presented  in  Figure  6.6-19 
and  Figure  6.6-20.  The  reference  configuration  requires  an  S&E  interface  for 
the  SDP's  with  local  buses  which  is  equivalent  to  the  MUX/DEMUX  function  on 
the  back-end  of  the  NIU  in  the  strawman  architecture.  Both  architectures 
support  options  for  the  back-end  of  the  NIU's.  The  selection  of  the  strawman 
architecture  can  have  multiple  options  resident  in  the  same  l\IIU  but  the 
reference  configuration  always  ha3  a single  back-end  port. 

Table  6.6-4  summarizes  the  comparison  of  the  two  architectures . The  strawman 
architecture  is  a distributed  system  which  minimizes  hardware  by  allowing  for 
full  distribution  of  functions  while  sacrificing  little  in  functional 
autonomy.  Autonomy  will  be  functional  instead  of  physical.  The  table 
hardware  count  and  software  size  is  expected  to  be  similar  in  either 
architecture  which  leads  to  the  recommendation. 


6.7  Buildup 

The  buildup  of  the  onboard  SSDS  is  partitioned  into  7 segments  that  are 
integrated  into  the  7 launch  packages.  Each  segment  is  ground  tested  after 
integration  with  the  launch  package.  The  DMS  launch  segments  are  then  placed 
in  an  unpowered  state  for  launch.  The  SDP  and  NIU  programs  for  flight  1 and  2 
are  stored  on  non-volatile  memory  resident  within  the  SDP  and  NIU.  The 
buildup  of  capabilities  and  onboard  SSDS  elements  on  a flight  basis  is 
presented  in  Table  6.7-1. 

For  the  buildup  sequence  discussed  in  the  following  subsections  reference  back 
to  Figures  6.6-1  and  6.6-2  will  be  required  to  identify  the  physical  locations 
of  the  onboard  SSDS  elements  discussed. 
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Fiber  Bus 


’Multiple  Backend  Ports. 
Combinations  Selectable 
From  DMA  to  SDP, 
Local  Bus 


Figure  6.6-19.  NIU/SDP  Configuration  For  Recommended  Architecture 


Fiber  Bus 


Figure  6.6-20.  NIU/SDP  Configuration  For  Ref  Configuration  Architecture 


6-112 


Table  6.6-4 


Architecture  Comparisons 


COMPONENTS  & 
FEATURES 

REFERENCE  CONFIGURATION 

STRAWMAN  ARCHITECTURE 

SOP  Hardware 

More  (needs  IOP) 

Less  (doesn't  need  IOP) 

NIL)  Hardware 

Less  in  any  one  unit 
but  same  back-end  options 

More  in  any  one  unit  but 
same  back-end  options 

SDP  Software 

More  complex  (I/O  Programs) 

Less  complex  (no  I/O  programs) 

NIU  Software 

Simpler 

More  complex  (I/O  programs, 
NOS  bypass  to  local  buses 

Fault  Tolerance 
Options 

Less  depth  in  sparing  (could 
use  same  system  S/W  failure 
detection) 

More  depth  in  sparing  (uses 
system  S/W  failure  detection) 

Subsystem  Autonomy 

Physical 

Functional 

Total  Hardware 

More  (dedicated  hardware) 

Less  (combine  functions) 

The  MRMS  is  activated  and  checked  out  for  subsequent  use  in  constructing  the 
Space  Station.  An  operational  scenario  requires  the  MRUS  software  to  be 
located  in  an  SDP  or  MPAC  located  in  the  orbiter  with  a hand  controller.  An 
RF  link  from  the  orbiter  to  the  MRMS  antenna  provides  the  media  for  video  and 
crew  commands.  The  MRMS  contains  the  electronics  and  mechanisms  for  arm 
movement.  The  software  can  be  recovered  for  subsequent  migration  to  HM1  Triad 
1 with  backup  in  SDP11.  The  HM2  operations  center  will  be  the  primary  MRMS 
control  station  with  a back  up  in  HM1 . 

6.7.1  Flight  1 

On  flight  1 the  transverse  boom  is  delivered  to  Space  and  deployed.  The 
flight  1 onboard  SSDS  configuration  consists  of  6 SDP's  6 NIU's,  3 master 
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TABLE  6.7-1 
BUILD-UP 


t 


1 

1 

1 

FLIGHT 

NUMBER 

| DMS 

1 ELEMENTS 

| DELIVERED 
1 

1 

| ADDED  FUNCTIONAL 

| SUPPORT 

.1 

1 

| ISSUES 

1 
1 

1 

1 

1 

1 ...  1 1 

1 

| SDP  1,2,3, 4,5,6 

| ATT  CONT 

| ACTIVATION 

1 

1 

1 

|NIU  1,2, 3, 4, 5, 6 

| NAV 

(MASS  MEMORY 

1 

1 

j RC  1 

| COM  I/F 

|DMS  BUS  INTEGRATION  ON  TRUSS 

1 

1 

|MTU  1,2,3 

| THM  TRANSVERSE 

|MRMS  CHECKOUT 

1 

I PWR  BOOM 

ICOMM  INTERFACE 

1 

1 

|NIU  7,8,9 

| RADIATOR  CONT 

j MRMS  CONTROL 

1 

1 

2 

|RC  2 

1 

(INTEGRATION  OF  PL  NETWORK  ON 

1 

IB  1 

I TRUSS 

| 

1 

| SDP  7,8,9 

| ECLSS  HM1 

| AIRLOCK  INTERFACE 

1 

1 

3 

|WS  1,2,3 

| PWR 

|WORK  STN.  NIU/LOCAL  BUS  PORTS | 

1 

| NIU  10,11,12,13 

| THM 

|COMM  I/F  TO  MASS  MEMORY 

1 

1 

1 14,15 

| ODB 

j WORK  STN  BUILD-UP  (NEED  3) 

1 

1 

| RC3 

|PROX  OPS 

| ASSEMBLY  OF  FIBER-TO-FIBER 

1 

1 

| 82 

| CREW  SYS  AIRLOCKS 

| CONNECTORS 

1 

|MMU  1 

IMECH 

| 

1 

|SDP  10,11,12 

| GUID  TRAFFIC  CONT 

1 

I 

1 

4 

| NIU  16,17,18,19 

j TRACKING  OMV  DEPLOY 

1 

1 

1 

| 20,21,22,23,24 

| RCS  LOWER 

| LOCAL  BUS  TO  RCS  AND  MAG 

1 

1 

|RC  4,5,6 

|MAG  TORQUER  KEEL 

j TORQUERS 

1 

1 

j B 3,4,5 

| PWR 

| DIRECT  GPS  INTERFACE 

1 

1 

|MMU  2 

|THM  HM2 

|COMM  I/F  CHANGE  FOR  UPPER 

1 

1 

i 

| ECLSS 

j BOOM  ADDITION 

1 

1 

i 

| PWR , THM,  GPS  UPPER 

1 

1 

1 BOOM 

| 

f 

i 

| PWR, THM  LOGISTICS 

1 

1 

1 

5 

| NONE 

| ECLSS  TRANSVERSE 

| LOGISTICS  MODULE  INTERFACE 

1 

1 

1 

j SOLAR  BOOM 

1 

1 ACT  EXT 

| 

f 

| SDP  13,14,15 

| PWR 

1 

| 

1 

6 

| NIU  25,26,27,28 

| THM 

1 

| 

1 

j 29,30,31 

j ECLSS 

1 

| 

1 

|RC  7,8 

| PL  PROC 

1 

| 

1 

IB  6,7 

j PL  UPPER  BOOM  DATA 

1 

| 

1 

jus  4,5 

| INTERFACE 

1 

| 

IMMU  4,5 

lAL  POINTING 

| 

f 

| SDP  16 

j PWR 

1 

| 

1 

7 

| NIU  32,33,34,35 

I THM  LAB  2 

| EARTH  VIEWING  PALLET 

| 

1 

| 36,37,38 

| ECLSS 

| REQUIREMENTS 

1 

1 

I B 8,9,10,11,12 

j PL  EARTH  VIEWING 

1 

| 

1 „ 

IMMU  3 

1 PALLET  INTERFACE 

1 
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timing  units  (MTU1,2,3)  and  a ring  concentrator  (RC1).  This  initial  portion 
of  the  onboard  SSDS  is  physically  located  on  the  Attitude  Control  Assembly 
(ACA) . Subsystem  functions  supported  are  attitude  determination,  attitude 
control  and  semi-autonomous  navigation  (ground  update). 

The  flight  1 onboard  SSDS  has  attitude  control  and  navigation  resident  in  one 
SDP  of  a triad  with  2 preferred  spares.  The  other  triad  has  electrical  power, 
thermal  control  and  the  communication  interface  programs  for  telemetry. 


6-7.2  Flight  2 

On  flight  2 the  lower  keel  and  lower  keel  extensions  are  attached.  The 
onboard  SSDS  elements  on  this  package  are  3 NIU's,  a ring  concentrator  (RC2) 
and  a bridge  (81)  to  connect  RC1  and  RC2 . The  added  NIU's  are  on  the  lower 
keel  extension  and  provide  communication  to  the  radiator  controls  (and 
eventually  the  RCS).  This  NIU's  also  support  lower  keel  electrical  power  and 
thermal  control.  Control  of  the  MRMS  is  through  telecommands  originating  in 
the  DMS  and  sent  through  RF  communication  channel. 


6.7.3  Flight  3 

On  flight  3 the  first  habitat  module  (HM1)  and  the  airlocks  (AL1 , AL2)  are 
delivered  and  attached.  The  onboard  SSDS  elements  in  this  package  are  3 
SDP's,  3 work  stations,  (WS's),  6 NIU's,  a mass  storage  unit  (MMU6),  a ring 
concentrator  (RC3)  and  a bridge  (B2).  This  configuration  supports  the  ECLSS 
subsystem  and  extensions  to  electrical  power  and  thermal  control.  The 
operational  data  base  can  now  use  the  external  mass  storage  unit  (previously 
it  was  using  local  memory).  The  crew  systems  and  mechanisms  associated  with 
the  airlocks  are  now  supported,  as  well  as  any  proximity  tracking  for 
approaching  the  airlocks.  The  core  network  optical  fibers  are  connected 
across  the  HM1  bulkhead  to  the  internal  bridge  (B2)  which  connects  to  RC3 . 
Work  Stations  for  crew  interface  are  available  at  multiple  stations. 
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6.7.4  Flight  4 


On  flight  4 the  upper  boom  is  assembled  and  habitat  module  2 (HM2)  is 
attached.  The  onboard  SSDS  elements  in  this  package  are  divided  into  the 
upper  boom  package  and  HM2  package.  In  the  upper  boom  package  there  are  6 
NIU's  (3  core  network  and  3 PL  network),  2 bridges  (B4,  B5)  and  2 ring 
concentrators  (RC5,  RC6).  The  core  network  elements  on  the  upper  boom  support 
remote  electrical  power  and  thermal  control  as  well  as  communication  to  the 
GPS  and  antennaes.  The  other  elements  are  put  in  place  for  PL  support  once 
the  PL  network  is  completed  (flight  6). 

The  habitat  module  2 had  3 SDP's,  3 NIU's,  a bridge  (B3)  and  ring  concentrator 
(RC4).  These  SDP's  have  the  facility  management  memory  configuration.  The 
NIU's  support  remote  sensing  and  control  by  ECLSS,  electrical  power  and 
thermal  control.  A local  bus  connector  is  also  on  these  NIU's  for  the 
logistics  module.  The  core  network  i3  extended  by  bringing  the  optical  fiber 
into  HM2  and  connecting  to  B3 . 


6.7.5  Flight  5 


On  flight  5 the  transverse  boom  port  and  starboard  extensions  are  attached. 

No  additional  onboard  SSDS  elements  are  delivered  on  this  flight.  Connectors 
on  local  buses  already  attached  NIU1,2,3  support  electrical  power  and  thermal 
control  on  the  extensions  as  well  as  the  solar  panel  actuators.  The  logistics 
module  is  also  attached.  Communication  to  the  logistics  module  is  on  a local 
bus  connected  from  HM2. 

6.7.6  Flight  6 

On  flight  6 labratory  module  2 (LM2)  is  attached.  The  onboard  SSDS  elements 
in  this  package  are  3 SDP's,  7 NIU's,  2 mass  memory  units  (MMU4,5),  2 ring 
concentrators  (RC7,8)  and  2 bridges  (B6,7)  and  2 work  stations  (WS4,5).  The 
PC  network  is  connected  across  the  LM2  bulkhead  and  connected  to  RC7.  The 
core  network  is  extended  by  bringing  the  optical  fiber  into  LM2  and  connecting 
to  87.  The  core  and  PL  networks  are  connected  across  B6  in  LM2. 
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Payload  processing  is  now  supported  in  the  SDP's  as  well  as  a PL  operational 
data  base.  The  PI  ODB  utilizes  two  MMU's  resident  in  LAB  2 on  the  PL  network. 

6.7.6  Flight  7 

On  flight  7 the  laboratory  module  1 (LMl)  is  attached.  The  onboard  SSDS 
elements  in  this  package  are  1 SOP,  7 IMIU's,  1 workstation  (WS6) , 1 mass 
memory  unit  (MMU3),  three  ring  concentrators  (RC9,10,11)  and  5 bridges 
(88,9,10,11,12).  The  remote  communication  to  core  functions  such  as  ECLSS, 
electrical  power  and  thermal  control  are  supported  on  local  buses.  The  SDP 
and  workstation  increase  the  PL  processing  capacity. 

The  PL  network  is  extended  across  a bulkhead  f iber-to-f iber  connector  to  reach 
the  Will’s  on  the  earth  viewing  pallet. 


6.8  Memory  and  Processing  Function  Sizing  Summary 

The  data  in  table  6.8  provide  summaries  of  the  memory  and  processing  loads  for 
the  Task  1 onboard  functions  grouped  in  terms  of  the  Reference  Configuration 
Subsystem  Wames. 
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Table  6.8 


TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
ELECTRICAL  POWER 


DATA  PROCESSING 


FUNCTIONS  MEMORY  (KBYTES!  (KOPS) 


IOC 

PROG  DATA 

GROWTH 
PROG  DATA 

IOC 

GROWTH 

4.2.1  OPERATE  POWER  SYSTEM 

4. 2. 1.1 

Eval.  Array  Per. 

5 

12 

18 

48 

2.5 

10 

4. 2. 1.2 

Conf.  Pw.  Dist. 

50 

150 

80 

300 

28 

50 

4.2.1 .3 

Power  Source  Mgmt. 

30 

100 

60 

200 

19 

35 

4.2.1 .4 

Array  Deployment 

1 

2 

4 

8 

0.5 

2 

4.2.1 .5 

Project  Energy  Avail. 

15 

6 

15 

6 

1 .2 

1 .2 

4. 2. 1.6 

Device  Mgmt 

50 

2 

100 

4 

25 

50 

4. 2. 1.7 

Cmmd  I/F  Proc. 

15 

5 

15 

5 

small 

smal  1 

166 

277 

292 

571 

76.2 

148.2 

TOTALS 

443 

863 

FUNCTIONS 

THERMAL 

CONTROL  SYSTEM 
MEMORY  (KBYTES) 

DATA 

PROCESSING 

(KOPS) 

IOC 

GROWTH 

IOC 

GROWTH 

PROG  DATA 

PROG 

DATA 

4.2.2  OPERATE  THERMAL 

CONTROL  SYSTEM 

4. 2. 2.1  Manage  T.  Load 

1 

1 

1 

2.5 

10 

15 

4. 2. 2. 2 Thermal  Device 

Mgmt 

50 

2 

100 

4 

0.5 

0.7 

4. 2. 2. 3 Project  Thermal 

Cop. 

1 

1 

1 

2.5 

0.33 

0.33 

4. 2. 2. 4 Cmmd  I/F  Proc. 

15 

5 

15 

5 

small 

smal  1 

67 

9 

117 

14 

10.9 

16.1 

TOTALS 

76 

131 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
GN&C  (Page  1 of  3) 

PROPULSION 

Contains  no  Task  1 Functions:  No  Software  Functions 


FUNCTIONS 

MEMORY  (KBYTES) 

OATA 

PROCESSING 

(KOPS) 

PROG 

IOC 

DATA 

GROWTH 
PROG  DATA 

IOC 

GROWTH 

1 .1 

NAV 

4.1 

.1 .1 

Spacecraft  Orb.  Det. 

20 

15 

30 

17 

20 

22 

4.1 

.1.2 

Const.  State/Orb  Det. 

50 

40 

75 

80 

12.5 

25 

4.1 

.1 .3 

Determine  Ephemerldes 
(Sun,  Moon,  etc.) 

2 

4 

3 

5 

0.02 

.03 

4.1 

.1 .4 

Attitude  Det. 

53 

20 

60 

22 

10 

12 

4.1 

.1.5 

Nav  State  Propag. 

20 

4 

25 

5 

5 

5.5 

4.1 

.1 .6 

Device  Mgmt 

30 

20 

40 

25 

15 

20 

4.1 

.1 .7 

Commd  I/F  Proc. 

10 

8 

12 

9 

4 

5 

185 

116 

245 

163 

66.6 

89.6 

301  408 


4.1.2  GUIDANCE 

4. 1.2.1 

Reboost/Reentry  Targ. 

20 

5 

25 

6 

2 

2.5 

4.1 .2.2 

Maneuver  Coord. 

18 

12 

30 

20 

0.5 

0.9 

4.1 .2.3 

Collision  Check 

20 

10 

25 

12 

0.83 

1 .0 

4.1 .2.4 

Reboost/Maneuver 

10 

4 

15 

06 

5 

6.0 

4. 1.2. 5 

Tether  Control 

- 

. - 

15 

4 

- 

0.1 

4.1 .2.6 

Det.  Pntg  Mt.  Cont. 

5 

1 

7 

1 .5 

5 

7 

4.1 .2.7 

Device  Mgmt. 

4 

1 

5 

02 

0.1 

0.2 

4.1 .2.8 

Cmmd  Interface  Proc. 

20 

5 

25 

07 

5 

7 

97 

38 

147 

58.5 

18.5 

24.7 

135 

205 

.5 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  HAP  TO  REFERENCE  CONFIGURATION 
GN&C  (Page  2 of  3) 


FUNCTIONS 

MEMORY  (KBYTES! 

DATA 

PROCESSING 

(KOPS) 

IOC 

GROWTH 

IOC 

GROWTH 

PROG 

DATA 

PROG  OATA 

1.3  ATTITUOE  CONTROL 

4. 1.3.1  Control  Aft  & Trans. 

48 

07 

56.2 

10.8 

150 

225 

4. 1.3. 2 Gen.  Attitude  Cmmds 

20 

4 

22 

5 

2 

2.5 

4. 1.3. 3 Momentum  Hgmt 

14 

1.8 

16 

2.0 

1.5 

2.0 

4. 1.3. 4 Pointing  Mt.  Control 

21 

4.0 

26 

6 

5.0 

7.0 

4.1 .3. 5 Device  Mgmt 

15 

4 

20 

6 

5.0 

6.0 

4.1 .3.6  Cmmd  I/F  Proc. 

30 

4 

32 

4.5 

6.0 

6.5 

148 

24.8 

172.2 

34.3 

169.5 

249 

172.8 

206. 

5 

1.4  TRAFFIC  CONTROL 

4. 1.4.1  Comp/Prop  Const  State 

8 

1 

9 

2 

1 

1 

4. 1.4. 2 Manage  Const.  Orb  Man 

10 

2 

15 

3 

1.5 

1 .8 

4. 1.4. 3 Sched.  Deploy/Rendez. 

5 

1 

6 

2 

0.1 

0.15 

4. 1.4. 4 Manage  Rendezvous 

5 

0.5 

9 

1 

0.05 

0.07 

4. 1.4. 5 Target  Coll.  Avoid. 

5 

1 

7 

2 

small 

smal 

4.1 .4.6  Cmmd  I/F  Proc. 

15 

2 

18 

__3 

smal  1 

smal 

48 

7.5 

64 

13 

2.7 

3.0 

55.5 

77 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
GN&C  (Page  3 of  3) 


FUNCTIONS 

MEMORY 

(KBYTES) 

OATA 

PROCESSING 

(KOPS) 

IOC 

PROG  DATA 

GROWTH 
PROG  DATA 

IOC 

GROWTH 

4.1.5  TRACKING 

4.1 .5.1  Long  Range 

40 

5 

50 

6 

5 

6 

4. 1.5. 2 Prox. 

40 

5 

50 

7 

5 

6 

4.1 .5.3  Object  Cat.  Main. 

25 

10 

30 

12 

.01 

.02 

4. 1.5. 4 Tracking  Oata  Cond. 

15 

2 

20 

4 

5 

6 

4.1 .5.5  Device  Mgmt 

20 

5 

25 

7 

0.5 

0.6 

4.1 .5.6  Cmmd  I/F  Mgmt 

20 

15 

25 

18 

4 

5 

160 

42 

200 

54 

19.6 

23.7 

202 

254 

2. 5. 3. 3 OTV  Deployment/Ret.  N/A 


5 10  small  small 


15 


2. 5. 4. 3 OMV  Deployment/Ret 


3 8 5 10  small  small 


11  15 


GN&C  TOTAL 


878  1181 


267  379 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
STRUCTURES/MECHANISMS 


DATA  PROCESSING 

FUNCTIONS  MEMORY  (KBYTES)  (KOPS) 


prog' 

IOC 

DATA 

GROWTH 
PROG  OATA 

IOC 

GROWTH 

4.2.3  STRUCTURES  & MECH  SUPPT 

4. 2. 3.1  Mechanism  Control 

7 

5 

14 

10 

1 

1.5 

4. 2. 3. 2 MRMS  Ups 

21 

10 

42 

20 

45 

90 

4. 2. 3. 3 Manage  Dock. /Berth. 

5 

4 

15 

12 

2 

6 

4. 2. 3. 4 Device  Mgmt 

10 

10 

20 

20 

0.5 

1 

4. 2. 3. 5 Cmmd  I/F  Proc 

27 

9 

74 

25 

3 

7.5 

70 

38 

165 

87 

51 .5 

106 

TOTALS 

108 

252 

ECLS 

4.2.4  ECLSS  OPERATION 

4. 2. 4.1  Control  Press/Atmos 

4 

5 

4 

5 

0.02 

0.02 

4. 2. 4. 2 Control  Temp/Hum 

4 

5 

4 

5 

0.02 

0.02 

4. 2. 4. 3 Potable  H20  Mgmt 

4 

5 

4 

5 

0.02 

0.02 

4. 2. 4. 4 Grey  Water  Mgmt 

4 

5 

4 

5 

0.02 

0.02 

4. 2. 4. 5 Fire  Det.  & Control 

4 

5 

4 

5 

0.02 

0.02 

4. 2. 4. 6 Device  Mgmt 

50 

2 

50 

4 

16.7 

16.7 

4. 2. 4. 7 Cmmd  I/F  Proc. 

15 

5 

15 

5 

small 

smal  1 

85 

32 

85 

34 

16.8 

16.8 

TOTALS 

117 

119 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  HAP  TO  REFERENCE  CONFIGURATION 
CREW  SYSTEMS  (Page  1 of  2) 


FUNCTIONS 


DATA  PROCESSING 

MEMORY  (KBYTES!  (KOPS) 

IOC  GROWTH  IOC  GROWTH 

PROG  DATA  PROG  DATA 


4.3.1  HEALTH  MAINTENANCE 

4. 3. 1.1  Crew  Phys.  Monitor 

4. 3. 1.2  Medical  Dlag.  Supt. 

4. 3. 1.3  Treatment  Supt. 

4. 3. 1.4  Nutrition  Anal. 

4. 3. 1.5  Exercise  Planner 

4. 3. 1.6  Phys.  Data  Trans  & 
Anal . 


5 2 7 3 

10  5 15  7 

5 3 7 5 

6 6 8 8 

10  5 15  7 

20  5 25  7 


0.04 
small 
0.02 
smal  1 
small 
small 


56  26 


77  37  0.07 


0.04 
smal  1 
0.03 
small 
smal  1 
small 

0.08 


82  114 


4.3.3  HABITABILITY 


4. 3. 3.1 

Recreation  Services 

4 

4 

8 

8 

small 

4. 3. 3. 2 

Crew/Grd  Comm 

0.4 

0.4 

1 

0.8 

small 

4. 3. 3. 3 

Cmmd  I/F  Proc 

0.2 

0.1 

0.4 

0.2 

small 

4.6 

4.5 

9.4 

9.0 

small 

small 
small 
small 
smal  1 


9.1  18.4 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
CREW  SYSTEMS  (Page  2 of  2) 


FUNCTIONS 

MEMORY  (KBYTES) 

DATA 

PROCESSING 

(KOPS) 

IOC 

GROWTH 

IOC 

GROWTH 

PROG 

DATA 

PROG  0ATA 

4.3.4  EVA  SUPPORT 

4. 3. 4.1  EMU  Contain  Control 

1 

0.5 

1 

0.5 

small 

smal  1 

4. 3. 4. 2 EMU  Moni tor/Mai nt. 

50 

2 

60 

4 

small 

smal  1 

4. 3. 4. 3 EMU  Monitor/Maint. 

20 

1 

30 

2 

small 

smal  1 

4. 3. 4. 4 Safety  Interlock  M/C 

1 

0.5 

2 

1 

small 

smal  1 

4.3.4. 5 EVA  Real  Time  M/C 

2 

1 

4 

2 

smal  1 

small 

* 4. 3. 4. 6 EVA  Visual  Info. 

50 

10 

75 

15 

100* 

100* 

4. 3. 4. 7 Airlock  Atmos  Pres. 

2 

0.5 

2 

0.5 

small 

smal  1 

Composition  Control 

4. 3. 4. 8 Airlock  Temp/Hum 

1 

0.5 

1 

0.5 

small 

smal  1 

4. 3. 4. 9 Device  Mgmt 

15 

1 

20 

2 

50 

75 

4.3.4.10  Cmmd  I/F  Proc 

15 

5 

20 

__7 

small 

smal  1 

TOTALS 

107* 

12* 

140* 

19.5* 

50 

75 

119 

159. 

5 

* 4. 3. 4. 6 Function  separate  f 

rom  DMS  System 

(Excluded) 

CREW  SYSTEM  TOTALS 

210.1 

291. 

9 

50.1 

75.1 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
COMM  & TRACKING  (Page  1 of  2) 

DATA  PROCESSING 

FUNCTIONS  MEMORY  (KBYTES)  (KOPS) 

IOC  GROWTH  IOC  GROWTH 


PROG 

DATA 

PROG 

DATA 

1.1  MANAGE  REAL  TIME  DATA 

ACTION 

1.1.1  Acquire  Real  Time 

10 

30 

20 

60 

100 

1 

1.1.2  Prioritize  Real  Time 

4 

2 

8 

4 

10 

1 

1.1.3  Monitor  Real  Time 

5 

2 

10 

4 

20 

SAME 

1.1.4  Dispatch  Real  Time 

10 

5 

20 

10 

50 

1 

1.1.5  Format  Real  Time 

20 

10 

40 

20 

80 

1 

49 

49 

98 

98 

260 

260 

98 

196 

1.2  MANAGE  OELAYABLE  DATA 

RETURN 

1.2.1  Acquire  Delayed  PL 

10 

200 

20 

400 

50 

1 

1.2.2  Prioritize  Delayed 

4 

2 

8 

4 

1 

1 

1.2.3  Monitor  Delayed 

5 

2 

10 

4 

2 

SAME 

1.2.4  Dispatch  Delayed 

10 

200 

20 

400 

50 

1 

1.2.5  Format  Delayed 

20 

10 

40 

20 

5 

1 

49 

414 

98 

828 

108 

108 

463  926 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
COMM  & TRACKING  (Page  2 of  2) 


FUNCTIONS 


MEMORY  (KBYTES) 

OATA 

PROCESSING 

(KOPS) 

IOC 

GROWTH 

IOC 

GROWTH 

PROG  DATA 

PROG  DATA 

4.2.5  COMMUNICATION 


4. 2. 5.1 

Network  Control 

35 

10 

50 

15 

small 

small 

4. 2. 5. 2 

Equipment  Control 

15 

15 

25 

10 

25 

35 

4. 2. 5. 3 

Status  Monitor 

50 

15 

70 

25 

2 

3 

4. 2. 5. 4 

Failure  Oetectlon/R. 

50 

64 

100 

128 

10 

20 

4. 2. 5. 5 

Cmmd  Prve 

5 

2 

10 

4 

10 

15 

4. 2. 5. 6 

Interface  Control 

5 

2 

6 

3 

5 

6 

4. 2. 5. 7 

Telemetry  Control 

5 

5 

5 

5 

200 

300 

165 

113 

266 

190 

252 

379 

278  456 


2. 5. 3. 5 OMV  Status 

(To  remote  customer) 


N/A 


N/A 


10  5 N/A 


3 


2. 5. 4. 6 OMV  Status 

(To  remove  customer) 


8 4 


10  5 2 


3 


COMM  8.  TRACKING  TOTALS 


851 


1608  622  753 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
INFORMATION  DATA  MANAGEMENT  SYSTEM  (Page  1 of  4) 


FUNCTIONS 


DATA  PROCESSING 

MEMORY  (KBYTES)  (KOPS1 

IOC  GROWTH  IOC  GROWTH 

PROG  DATA  PRQG  DATA 


2.1  Validate  PL  Cmmd 


2.2  Check  SSDS  Ser.  Req. 
Restriction/Constraint 


4 20  6 40  0.01  0.03 

24  46 

20  50  30  100  1.7  3.75 


2.3  Validate  Core 

Cmmd/Data  .1 

4 

20 

6 

40 

2.3.1  and  2.3. 

.2  .2 

10 

25 

15 

50 

small 

smal  1 

14 

45 

21 

90 

3.3  Develop  Ops  Event  Scld.  214  510  240  590  0.6  0.7 

3.3.1  to  3.3.4  

724  830 

3.4  Sequence  Operations  42  18  59  29  small  small 

3.4.1  to  3.4.4  

60  88 

4.3.2  Space  Station  Safety  7.5  7 18  19  small  small 

4. 3. 2.1  to  4. 3. 2. 4 

14.5  37 


4.3.5  OPS  & Procedure  Supt.  140  153  152  152  0.3  0.7 

4. 3. 5.1  to  4. 3. 5. 5 

293  304 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
INFORMATION  DATA  MANAGEMENT  SYSTEM  (Page  2 of  4) 


OATA  PROCESSING 

FUNCTIONS  MEMORY  (KBYTES)  (KOPS) 


IOC 

GROWTH 

IOC 

GROWTH 

PROG  DATA 

PROG 

OATA 

4.1.6  Time  & Frequency  Mgmt. 

4.1 .6.1  Time  Source 

0.5  0.2 

0.7 

0.3 

0.2 

0.3 

4.1 .6.2  Time  Update 

2 0.5 

3 

1 

small 

smal  1 

4. 1.6. 3 Freq.  Source  Mgmt 

1 0.3 

2 

0.5 

0.5 

0.7 

4.1 .6.4  Device  Mgmt 

0.3  0.1 

0.5 

0.2 

0.2 

0.3 

4.1 .6. 5 Cmmd  I/F  Proc . 

0.2  0.1 

0.4 

0.2 

small 

small 

4.0  1.2 

6.6 

2.2 

0.9 

1 .3 

5.2 

8.8 

5.1.1  Fit.  Data  Base  Mgmt. 

5. 1.1.1  Update/Access  Synch 

250  50 

500 

100 

small 

smal  1 

5.1 .1 .2  Data  File  Mgmt. 

12  140 

20 

200 

small 

small 

5. 1.1. 3 Mass  Memory  Res.  Mgmt 

10  4 

20 

10 

small 

small 

5. 1.1. 4 Archival  Storage 

20  5 

40 

10 

small 

small 

5.1 .1 .5  Device  Mgmt 

1 0.5 

2 

1 

1 

1 .5 

5.1 .1 .6  Cmmd  I/F  Proc. 

1 0.5 

2 

1 

small 

small 

294  200 

584 

322 

1 

1 .5 

494  906 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
INFORMATION  DATA  MANAGEMENT  SYSTEM  (Page  3 of  4) 


DATA  PROCESSING 

FUNCTIONS  MEMORY  ( KBYTES1  ( KQPS1 


IOC 

GROWTH 

IOC 

GROWTH 

PROG  DATA 

PROG 

DATA 

5.1.2  Fit.  Resource  Mgmt. 

5. 1.2.1  Load  Scheduling 

5 

5 

10 

10 

small 

small 

5. 1.2. 2 System  Executive 

% of 

% of 

- OPERATING  SYS.  (OS)* 

160 

250 

Application 

Application 

- Network  OS  (NOS)* 

410 

450 

100 

130 

5. 1.2. 3 Initialized  Conf.  Cont 

30 

18 

50 

30 

small 

small 

5. 1.2. 4 Conflgur.  Oata  Proc. 

50 

125 

100 

200 

smal  1 

smal  1 

5. 1.2. 5 Facility  Status 

22 

60 

40 

80 

small 

small 

5. 1.2. 6 Recept.  01st.  PL 

80 

175 

100 

200 

30 

50 

5.1 .2.7  Device  Mgmt. 

10 

20 

20 

30 

0.2 

0.2 

5.1 .2.8  Cmmd  I/F  Proc 

15 

5 

25 

10 

0.5 

1.0 

212 

408 

345 

560 

30.7 

51.2 

620 

905 

*5. 1.2. 2 Excluded  from  5.1.2 

total 

because 

OS  applies 

to  memory 

configuration  and  NOS  Is 

contalnec 

1 In  NIU. 

5.1 .3  Displays  & Controls 

5.1 .3.1  Device  Mgmt 

0.4 

0.2 

0.5 

0.3 

5. 1.3. 2 Cmmd  I/F  Proc 

0.2 

0.1 

0.4 

0.2 

0.6  0.3 

0.9  0.5 

0.9 

1.4 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
INFORMATION  DATA  MANAGEMENT  SYSTEM  (Page  4 of  4) 


FUNCTIONS 

MEMORY  (KBYTES) 

OATA 

PROCESSING 

(KOPS) 

IOC 

GROWTH 

IOC 

GROWTH 

* 

PROG  DATA 

PROG  DATA 

4.5  Monitor  & Status  System 

4.5.1  Monitor  Core 

4 

2 

8 

4 

0.5 

1 

4.5.2  Monitor  Customer 

4 

2 

8 

4 

0.4 

0.8 

4.5.3  Mass  Prop.  Conf. 

7 

3 

14 

6 

0.1 

0.2 

4.5.4  Diagnostic  Suppt. 

4. 5. 4.1  to  4. 5.4.3 

45 

42 

405 

82 

4.5 

40.5 

4.5.5  System  Test  & Eval 

20 

15 

20 

15 

1 .0 

2.0 

4.5.6  Cmmd  I/F  Proc. 

52 

17 

134 

59 

3.0 

9.0 

132 

81 

589  170 

9.5 

53.5 

213 

759 

IDMS  TOTALS 

2511.6 

4036. 

2 

44.8 

112.i 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  HAP  TO  REFERENCE  CONFIGURATION 
PAYLOAD  ANO  SERVICING  ACCOMMODATIONS  (Page  1 of  2) 

DATA  PROCESSING 

FUNCTIONS  MEMORY  (KBYTES1  (KOPS) 

IOC  GROWTH  IOC  GROWTH 


PROG 

DATA 

PROG 

DATA 

2.4  Provide  Ancillary  Data 

2 

10 

3 

20 

4.4 

9.0 

2.5  Support  Customer  Ops 

12 

23 

2.5.1  Customer  Data  Proc. 

100* 

100* 

200* 

200* 

0.02 

0.02 

2.5.2  Customer  PL  OPS 

25 

25 

50 

50 

small 

smal  1 

2.5.3  Support  OTV  OPS 

2. 5. 3.1  OTV  Service 

N/A 

N/A 

25 

10 

N/A 

0.1 

2. 5. 3. 2 OTV  CO  & Dlag 

N/A 

N/A 

100 

100 

N/A 

0.5 

2. 5. 3. 4 OTV  Operation 

N/A 

N/A 

10 

20 

N/A 

smal  1 

25 

25 

185 

180 

0.1 

0.7 

W/0* 

50* 

365* 

2.5.4  Support  OMV  OPS 

2. 5. 4.1  OMV  Service 

15 

6 

25 

10 

small 

small 

2. 5. 4. 2 OMV  CO  & Dlag. 

75 

75 

100 

100 

smal  1 

smal  1 

2. 5. 4. 3 Remote  Ops  Co. 

15 

6 

21 

10 

10 

15 

2. 5. 4. 5 OMV  OPS 

8 

15 

10 

20 

small 

smal  1 

113 

102 

156 

140 

10 

15 

■ . 

215 

296 

2.5.5  Customer  Payload 

25 

1000 

30 

1200 

smal  1 

small 

Checkout  Service 

1025 

1230 

2.6  SSPE  CO  AND  SERVICE 

100 

1000 

100 

1000 

small 

small 

1100  1100 
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Table  6.8  (continued) 

TASK  1 FUNCTIONS  HAP  TO  REFERENCE  CONFIGURATION 
PAYLOAD  AND  SERVICING  ACCOMMODATIONS  (Page  2 of  2) 


DATA 

PROCESSING 

FUNCTIONS 

MEMORY  (KBYTES) 

(KOPS) 

IOC 

GROWTH 

IOC 

GROWTH 

PROG  DATA 

PROG  DATA 

.4  Provide  Cust.  Avionic  Sev 

4.4.1  GN&C  Service 

4.4.1 .1  Grd  Track 

3 1 

6 2 

0.5 

1 

4. 4. 1.2  Magnetic  Field 

1.5  0.5 

1.5  0.5 

0.3 

1 

4.4.1 .3  Pallet  Coarse 

10  2 

20  4 

10 

20 

4.4.1 .4  Relative  Align 

13  9 

13  9 

0.2 

0.2 

27.5  12.5 

40.5  15.5 

11 

22.2 

40 

56 

4.4.2  Contamination  Control 

4. 4. 2.1  Venting  Effects 

8 4 

24  12 

0.2 

0.6 

4. 4. 2. 2 Environ.  Monitor 

12  8 

24  16 

0.4 

0.8 

20  12 

48  28 

0.6 

1 .4 

32 

76 

4.4.3  Tracking  Services 

3 1 

9 3 

0.1 

0.3 

4 

12 

PAYLOAD  AND  SERVICING  ACC. 

TOTALS 

2478 

3158 

26.2 

48.6 
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6.9  ONBOARD  PLATFORM  SSDS  DEFINITION 


6.9.1  Introduction  and  Overview 

This  section  presents  an  overview  of  the  onboard  Platform  SSDS.  The  SSDS 
includes  the  onboard  networks,  the  network  interface  units  (NIU's),  subsystem 
data  processors  (SDP),  mass  storage  units  and  the  software  that  resides  in  or 
supports  these  elements.  Subsystem  application  software  is  included  in  this 
definition.  The  architecture  and  system  definition  described  herein  are 
products  of  the  SSDS  A/A  Study  approach  and  methodology  outlined  in  Section 
2.0.  This  architecture  definition  is  preliminary.  Some  elements  are  defined 
in  more  detail  than  others  to  explore  specific  design  or  technology  driver 
aspects  of  the  architecture . The  prime  inputs  used  are  the  same  as  those 
detailed  in  Section  6.1 

The  major  metrics  utilized  throughout  this  task  to  evaluate  architectural 
alternatives  and  influence  key  design  decisions  are  the  same  set  described  in 
Section  6.1. 

The  primary  steps  of  the  platform  onboard  system  definition  process  proceeded 
in  a similar  manner  to  that  described  in  Section  6.1  for  the  Space  Station 
SSDS. 


The  supporting  trade  study  results  and  options  developed  were  major  inputs 
into  the  system  definition  process.  Recommendations  and  supporting  data  in 
the  Space  Station  trade  studies  and  related  options  catagories  were  important 
influencing  factors  in  most  key  design  decisions.  Commonality  was  a key 
consideration  in  all  tjsese  trade  studies  and  in  our  platform  system  design. 
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6.9.2  Partitioning  of  Functional  Requirements  into  Onboard  Subsystems 

The  same  process  reported  in  Section  6.2  for  the  Space  Station  SSDS  was 
followed  for  the  platform. 

Table  6. 9. 2-1  presents  an  application  overview  of  memory  sizing  in  kilobytes 
(kbytes)  and  mean  processing  rates  in  kilo-operations  per  second  (kops)  using 
the  reference  configuration  subsystem  names.  A detailed  breakout  of  each  of 
the  subsystems  are  tabulated  in  Section  6.9.8. 

The  application  memory  size  for  each  subsystem  is  conservative  from  the 
standpoint  that  it  represents  an  arithmetic  sum.  Wot  all  elements  of  each 
subsystem  are  necessarily  main  memory  resident  in  an  SDP  at  all  times.  This 
also  naturally  applies  to  their  computational  rates 

6.9.3  Subsystem  Allocation  in  Architectural  Elements 

The  discussion  of  Section  6.3  for  Space  Station  in  general  applies  equally 
well  to  the  platform.  The  basic  difference  is  in  the  sizing  values  for  each 
memory  conf iguration . Table  6. 9. 3-1  provides  the  summary  data  by  memory 
configuration.  Section  6.9.8  provides  the  detailed  sizing  data  extracted  from 
the  Task  A,  Appendix  G which  contains  the  sizing  data  for  all  the  platform 
functions . 

The  major  differences  between  the  Platform  System  and  Space  Station  are  the 
smaller  and  fewer  application  functions.  The  following  is  a brief  difference 
summary : 

1.  No  ECLS  is  required  for  the  Platform  (Functions  4.2.4. 1-7) 

2.  No  onboard  Displays  and  Controls  are  required  (5.1.3) 

3.  Some  Space  Station  GN&C  functions  are  not  required  for  the  platform: 

- Traffic  Control  (4.1.4) 

-Tracking  (4.1.5  and  4.4.3) 

4.  No  onboard  Displays  and  Controls  are  required  (5.1.3) 

5.  The  remaining  onboard  functions  are  required,  but  are  reduced  in  size. 
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Table  6. 9. 2-1 


TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
SUMMARY  DATA 


SUBSYSTEM 

1.  ELEC  PWR 

4. 2. 1.1- 7 

2.  GN&C  370  468  190  255 

4.1,  2. 5.3.3,  2. 5. 4. 3 

3.  THERMAL  CONTROL  68  127  3 4 

4. 2. 2. 1- 4 


4.  ECLS  NOT  APPLICABLE  TO  PLATFORM 

4. 2. 4. 1- 7 

5.  PROPULSION  NO  SOFTWARE  — CONTROLLED  BY  GN&C 

6.  STRUCTURES/MECHANISMS  24  43  35 

4. 2. 3. 1- 5 

7.  CREW  SYSTEMS  NOT  APPLICABLE  TO  PLATFORM 

4.3.1,  4.3.3,  4.3.4 

8.  COMM  & TRACKING  606  1077  499  747 

1.1. 1- 5,  1.2. 1-5, 

4. 2. 5. 1- 7,  2. 5. 3. 5, 

2. 5. 4. 6 

9.  INFORMATION  & 2271  3689  42  84 

DATA  MGMT  SYSTEM 

2.1,  2.2,  2.3,  3.3,  3.4 
4.3.2,  4.3.5,  4.5, 

4.1.6,  5.1.1,  5.1.2 

10.  PL  & SERVICING  2231  2801  15  29 

ACCOMMODATIONS 

2.4,  2.5.1,  2.5.2, 

2. 5. 3.1,  2. 5. 3. 2, 

2. 5.3.4,  2.5.4,  2.5.5, 

4.4 


KBYTES! 

GROWTH 

227 


MEAN  DATA 
PROCESSING  ( K0PS1 
IOC  GROWTH 

69  127 
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Table  6. 9. 3-1 


Platform  SSDS  Core  and  Payload  Memory  Configurations 


Wo. 

Name/Function 

IOC 

Mem(1>/CPu(2) 

(KBYTES/KOPS) 

Growth 

Mem(1)/CPu(2) 

(KBYTES/KOPS) 

1 . 

GN&C 
o NAV 
o Guidance 
o ATT  Cont 

370/2197 

718/293 

2. 

o Elec  Pwr 
o Thermal  Control 
o Communications 
o Str.  & Mechanisms 

961/660 

1724/1016 

3. 

Information  & Data 
Managememt  System 

2431/48 

3939/97 

4. 

Payload  and  Servicing 
Accommodations 

2391/17 

3051/66 

5. 

Payload  Processing 
(Function  2.5.1) 

360/1 

650/1 

6. 

Payload  Processing 
(Function  2.5.1) 

360/1 

650/1 

(1)  Application  size  from  Tables  6. 2-1/6. 8-1  +160  KBYTES  for  operating  system 
(+250  KBYTES  for  growth). 

(2)  KOPS  from  Table  6 . 9 . 2-1  + 15%  of  total  application  KOPS  for  operating 
system  overhead. 
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6.9.4 


Architecture 


6.9.4. 1 Overall  Partitioning 

The  overall  platform  architecture  presented  here  has  most  of  the  same 
connectivity  generalized  in  the  NASA  Reference  Configuration.  However,  the 
system  definition  process  of  this  study  has  resulted  in  a more  specific  and 
detailed  configuration. 

6. 9. 4. 2 Network  Configuration 

A major  deviation  from  the  Reference  Configuration  is  the  partitioning  of  the 
network  into  two  networks:  core  and  payload.  The  reasoning  for  this  decision 
is  the  same  as  for  the  Space  Station  as  discussed  in  Section  6.4.2. 

The  discussion  in  Section  6.4.2  concerning  the  network  configuration,  level  of 
standardization,  transmission  media,  topology  and  media  access  method  and 
communication  functions  equally  apply  to  the  onboard  platform  SSDS. 

6. 9. 4. 3 NIU  Functional  Description 

The  NIU  for  the  platform  is  the  same  one  as  the  Space  Station.  Again, 
commonality  was  the  key  driver  in  this  decision.  Basic  hardware  and  software 
functionality  is  the  same  in  both  systems. 

6. 9. 4. 4 Operating  System/Application 

The  discussion  for  the  Space  Station  on  this  subject  applies  to  the  Platform 
system.  As  discussed  earlier,  their  are  fewer  functions  on  the  Platform  than 
the  Space  Station.  Most  of  the  platform  application  functions  will  require 
the  same  support  services  as  the  Space  Station.  The  most  notable  difference 
are  Displays  and  Controls  and  other  onboard  man  machine  interfaces.  A common 
DOS  and  OS  as  described  in  Section  6.4.4  is  recommended  for  the  Platform  to 
take  advantage  of  reduced  development  and  maintenance  costs  for  both  systems. 
It  might  be  possible  to  build  the  man-machine  interfaces  in  the  common  DOS/OS 
so  that  they  can  be  excluded  for  the  platform  system  to  save  memory. 
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6.9. 4.5  Subsystem  Data  Processor 


It  is  recommended  that  a common  subsystem  data  processor  (SOP)  be  used  for 
both  the  Platform  and  the  Space  Station.  The  characteristics  of  the  SOP  were 
discussed  in  Section  6.4.5. 

6. 9. 4. 6 Onboard  Workstations 

There  are  no  onboard  work  stations  for  the  Platform.  This  section  was 
retained  to  keep  a similar  numbering  system  for  traceability  to  the  Space 
Station  sections. 

6. 9. 4. 7 Operational  Data  Base 

The  same  general  needs  for  an  operational  base  and  mass  storage  exist  for  the 
Platform  as  for  the  Space  Station  (ref.  section  6.4.7).  The  size  for  the 
Platform  system  is  greatly  reduced  because  the  Platform  is  unmanned  and 
maintenance  will  be  performed  at  discrete  intervals. 

6. 9. 4. 8 Communication  Gateway 

The  discussion  for  this  subject  is  the  same  as  that  for  the  Space  Station 
(ref.  section  6.4.8). 
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6. 9. 4. 9 PLATFORM  TRAFFIC  ANALYSIS 


The  following  section  derived  the  network  traffic  requirements  for  the 
platforms.  The  requirements  are  presented  In  terms  of  messages  per  second,  a 
more  meaningful  traffic  parameter  than  bytes  per  second.  Analysis  of  the  core 
network  traffic  model  shows  the  communication  and  tracking  NIU  receives  over 
2/3  of  the  total  traffic  load. 

The  network  traffic  model  was  derived  from  the  McDonnell  Douglas 
Requirements  Data  Base  (Appendix-1)  using  an  analysis  tool  developed  In  PL/I. 
The  tool  allows  functions  In  the  Data  Base  to  be  arbitrarily  distributed 
across  a multi-computer  environment.  The  process  allows  the  operator  to 


Interactively  specify,  for  example: 
Computer  Computer 

Computer 

Computer 

1 2 

N-l 

N 

Function  # Function  # 

External  1 

External  3 

1.1.1  2.1.1 

External  2 

1.1.2  4.3.1 

From  this  Input,  a search  of  the  data  base  Is  made  to  determine  the 
following  reports: 

Computer  1 to/from  Computer  2 

Computer  1 and  2 to  External  Sets  1 and  2 

Computer  1 and  2 to  External  Set  3 

Proper  selection  of  the  Inputs,  functions  and  externals,  resulted  In 
statistical  reports  to  evaluate  the  I/O  requirements.  From  these  Inputs  the 
following  statistics  were  determined: 

Subsystem  to  subsystem  I/O 
Subsystem  to  subsystem  sensors/effectors 
Subsystem  to  operational  data  base,  ancillary  data 
Subsystem  to  displays 

Subsystem  to  Comm  for  telemetry,  operations  Instrumentation  data 

The  network  traffic  model  was  developed  from  several  sources: 

(1)  Analyses  of  Functions  Data  Base  I/O  Relationships 

(2)  Engineering  Modifications  to  (1)  Above 

(3)  Engineering  Judgement 
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Additions  to  the  Network  Traffic  Model  Included: 

(1)  Telemetry  Data 

(2)  Operations  Instrumentation  Data 

(3)  Ancillary  Data 

(4)  Ground  Forward  Commands 

Table  6. 9. 4. 9-1  Identifies  specific  assumptions  employed  In  the  network 
traffic  analysis.  Figure  6. 9. 6. 1-1  shows  the  processing  distribution  for  the 
core  network. 


Table  6. 9. 4. 9-2  shows  the  core  network  traffic  results  for  the  platforms. 
The  traffic  due  to  telemetry  Is  approximately  2/3  of  the  total  load  on  the 
core  network. 


6.9.4.10  Fault  Tolerance 

The  basic  discussion  in  Section  6.4.10  applies  to  the  Platform 

6.9.4.11  Time  Management 

The  discussion  in  Section  6.4.11  applies  to  the  Platform  because  this  basic 
service  is  needed  in  both  systems  with  the  same  degree  of  accuracy  and 
availability.  A common  system  design  is  recommended  to  save  costs. 
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TABLE  6. 9. 4. 9-1  NETWORK  I/O  TRAFFIC  ASSUMPTIONS 


o Requirement  Sources 

- Analysis  of  core  traffic  results  and  engineering  judgement  to  model 
remaining  non-telemetry  payload  network  traffic  nodes 

o Topology 

- Flles/Data  stores  In  each  Subsystem  SDP 

- OMS  00B  has  It's  own  SDP 

o Packet/Message  Length 

- Message  length  equals  packet  length 

o Telemetry 

- 25  KBytes/sec  per  Subsystem 

- 1 KByte  Message  size  to  satisfy  Consultative  Committee  for  Space  Data 
Systems  (CCSDS)  efficiency 

o Overhead 

- OSI/CCSOS  message  overhead  not  Included 

o Ancillary  Data  (AD) 

- Subsystems  send  AD  to  DMS  ODB 

- DMS  ODB  blocks  AD  and  sends  to  P/L  Network  OOB 

- P/L's  read  AD  from  P/L  ODB  as  required 

o Ground  Forward  Commands  (GFC) 

- Comm  receives  GFC  for  each  subsystem 

- Comm  routes  GFC  to  Individual  Subsystems 

- Dependent  on  CMD  VAL  Implementation 

- 0.1  message/sec  per  subsystem 

o Operations  Instrumentation  Data  (OID) 

- OID  collected  by  each  subsystem  from  backend 

- Subsystem  send  blocked  OID  to  COMM  for  downlink 
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TABLE  6. 9. 4. 9-2  PLATFORM  CORE  TRAFFIC  ANALYSIS 


6.9.5 


Operational  Scenarios 


With  the  exception  of  the  discussion  for  onboard  manned  operations,  the  system 
initialization,  subsystem  control,  facility  management,  telemetry  and 
commands,  and  examples  of  onboard  data  flow  for  the  Space  Station  (ref. 
section  6.5)  applies  equally  well  to  the  Platform. 

6.9.6  Onboard  Platform  SSDS  Architecture 

6.9.6. 1 Distribution  of  Processing 

The  Platform  SSDS  architecture  and  Space  Station  architecture  are  functionally 
the  same.  They  differ  only  in  specific  subsystem  needs  and  in  physical 
configuration  of  the  spacecraft  structures.  Commonality  and  the  resultant 
cost  savings  were  key  considerations.  Our  studies  show  that  commonality  with 
the  Space  Station  does  not  significantly  compromise  the  SSDS  differences 
between  specific  needs  for  the  two  systems.  For  example,  the  memory  size  and 
computational  speed  of  the  SDP  can  be  based  on  convenient  subsystem  groupings 
for  both  systems  with  adequate  margins.  Both  systems  need  to  support  core  and 
payload  functions;  both  need  an  operating  system  (OS)  and  a distributed 
operating  system  (DOS)  to  interface  similar  core  sensors  and  effectors  and 
payload  measurements  with  their  respective  application  software  programs.  For 
the  above  reasons,  a functionally  common  architecture  is  recommended  for  both 
systems . 

The  main  features  cited  in  Section  6.6.1  for  the  Space  Station  applies  to  the 
Platform  with  the  exception  of  using  a workstation  to  offload  processing  from 
the  SDP's. 


The  Platform  SSDS  memory  configurations  and  their  respective  distribution  are 
presented  in  Table  6.9.6. 1-1.  The  six  memory  configurations  are  supported  by 
18  SDP,  and  NIU  pairs.  The  SDP  sparing  strategy  is  two  backups  for  all  memory 
configurations. 

The  total  network  that  supports  this  distribution  is  shown  Figure  6.9.6. 1-1 
and  Figure  6.9.6. 1-2.  The  PL/EXP  and  core  functions  are  separated  to  insure 
the  highest  degree  of  trafffic  isolation  and,  therefore  function  autonomy. 
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Table  6. 9. 6. 1-1  PLATFORM  MEMORY  CONFIGURATIONS 
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Memory 
Configuration  3 


Figure  6.9.6.1-1.  Platform  Processing  Distribution 
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Figure  6.9.6.1-2.  Platform  Processing  Function 


6. 9. 6. 2 


Platform  Network  Architecture 


The  Platform  "strawman"  onboard  local  area  network  configuration  consists  of 
two  major  network  partitions  isolating  PL/EXP  traffic  from  core  traffic. 

There  is  a bridge  between  the  two  network  partitions  to  support  core  and 
PL/EXP  data  exchange.  Ancillary  data  and  forward  link  telemetry  flow  from 
the  core  network  to  the  PL/EXP  network  across  the  bridge.  The  topology  of  the 
network  is  the  same  as  the  Space  Station;  interconnected  dual  redundant  token 
rings  each  with  a multi-port  ring  concentrator . The  physical  distribution  of 
the  network  elements  is  shown  in  Figure  6. 9. 6. 2-1.  The  network  topology  is 
shown  in  Figure  6. 9. 6. 2-2.  Dual  redundancy  exists  in  the  bridges  and  ring 
concentrators . 

6. 9. 6. 3 Major  Architecture  Issue 

The  architecture  issue  discussed  in  Section  6.6.3  for  the  Space  Station  also 
applies  to  the  Platform  SSDS  architecture. 

6.9.7  Buildup 

The  assumption  is  made  that  the  platform  is  assembled  with  one  NSTS  flight  and 
to  date  no  impacts  have  been  identified  to  the  Platform  SSDS  Architecture . 

6.9.8  Platform  Memory  and  Processing  Function  Summary 

The  data  in  Table  6.9.8  provides  summaries  of  the  memory  and  processing  loads 
for  the  Task  1 and  Task  4 onboard  functions  grouped  in  terms  of  the  Reference 
Configuration  Subsystem  names.  The  Task  1 and  Task  4 Appendices  provide 
detailed  function  descriptions  and  sizing  data. 
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Figure  6. 9.6. 2-1.  Platform  Physical  Distribution 
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Table  6.9,8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 


ELECTRICAL  POWER 


DATA  PROCESSING 

FUNCTIONS  MEMORY  (KBYTES)  (KOPS) 


IOC 

PROG  DATA 

GROWTH 
PROG  DATA 

IOC 

GROWTH 

4.2.1  OPERATE  POWER  SYSTEM 

4.2. 1.1 

Eval,  Array  Per. 

5 

4 

6 

6 

2.5 

2.5 

4.2. 1.2 

Conf.  Pw.  Dist. 

10 

12 

60 

24 

28 

50 

4.2. 1.3 

Power  Source  Mgmt. 

10 

10 

20 

20 

19 

35 

4.2. 1.4 

Array  Deployment 

1 

2 

4 

4 

0.5 

2 

4 . 2 . 1 . 5 

Project  Energy  Avail. 

10 

2 

15 

5 

1.2 

1.2 

4.2. 1.6 

Device  Mgmt 

25 

1.5 

50 

3 

18 

36 

rH 

CM 

Cmmd  I/F  Proc . 

7 

3 

7 

3 

small 

small 

68 

34.5 

162 

65 

69.2 

126.7 

TOTALS 

102. 

5 

227 

THERMAL 

CONTROL 

SYSTEM 

FUNCTIONS 

MEMORY 

(KBYTES) 

DATA 

PROCESSING 

(KOPS) 

IOC 

PROG  DATA 

GROWTH 
PROG  DATA 

IOC 

GROWTH 

4.2.2  OPERATE  THERMAL 


CONTROL  SYSTEM 


4.2.2. 1 

Manage  T . Load 

1 

3 

i 

4.5 

0.13 

0.20 

4. 2. 2. 2 

Thermal  Device  Mgmt 

50 

2 

100 

4 

2.5 

3.5 

4. 2. 2. 3 

Project  Thermal  Cop. 

1 

1 

1 

2.5 

0.33 

0.33 

4. 2. 2. 4 

Cmmd  I/F  Proc. 

7 

3 

_10 

4 

small 

smal  1 

59 

9 

112 

15 

2.96 

4.03 



„ 



TOTALS  68  127 


PROPULSION 

Contains  no  Task  1 Functions:  No  Software  Functions 
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Table  6.9.8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 


GN&C  (Page  1 of  3) 


FUNCTIONS 

MEMORY 

(KBYTES) 

DATA 

PROCESSING 

(KOPS) 

IOC 

PROG  DATA 

GROWTH 
PROG  DATA 

IOC 

GROWTH 

4.1.1  NAV 

4. 1.1.1  Spacecraft  Orb.  Det. 

20 

15 

30 

17 

20 

22 

4. 1.1.2  Const.  State/Orb  Det. 

NOT  APPLICABLE 

TO  PLATFORM 

4. 1.1. 3 Determine  Ephemerides 

2 

4 

3.5 

5 

0.02 

.02 

(Sun,  Moon,  etc.) 

4. 1.1. 4 Attitude  Det. 

35 

14 

42 

16 

5 

7 

4. 1.1. 5 Nav  State  Propag. 

20 

4 

25 

5 

5 

5.5 

4. 1.1. 6 Device  Mgmt 

20 

15 

25 

20 

10 

12 

4. 1.1. 7 Commd  I/F  Proc . 

5 

4 

6 

5 

_2_ 

3 

102 

56 

131.5 

68 

42. 1 

49.5 

TOTALS 

158 

199.5 

4.1.2  GUIDANCE 

4.1.2. 1 

Reboost/Reentry  Targ. 

14 

3.5 

18 

4,5 

1.4 

2.0 

4. 1.2. 2 

Maneuver  Coord. 

12 

8 

20 

12 

.35 

0.6 

4. 1.2. 3 

Collision  Check 

NOT  APPLICABLE 

TO  PLATFORM 

4. 1.2.4 

Reboost /Maneuver 

7 

2.8 

10 

3.2 

3.5 

4.5 

4. 1.2. 5 

Tether  Control 

NOT  APPLICABLE 

TO  PLATFORM 

4. 1.2.6 

Det.  Pntg  Mt.  Cont. 

2.5 

0.5 

3.5 

.75 

. 75 

i 

4. 1.2.7 

Device  Mgmt. 

1.2 

0.3 

1.5 

.6 

.03 

.04 

4. 1.2.8 

Cmmd  Interface  Proc. 

6 

1.5 

7 

2 

3 

4 

42./ 

' 16.6 

60 

23.1 

9.1 

12.1 

TOTALS 

59. 

3 

83 

. 1 

C - ^ 
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Table  6.9.8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 

GN&C  (Page  2 of  3) 


FUNCTIONS 

MEMORY 

(KBYTES) 

DATA 

PROCESSING 

(KOPS) 

PROG 

IOC 

DATA 

GROWTH 
PROG  DATA* 

IOC 

GROWTH 

4.1.3  ATTITUDE  CONTROL 

4. 1.3.1 

Control  Aft  & Trans. 

48 

7 

56.2 

10.8 

125 

175 

4. 1.3. 2 

Gen.  Attitude  Cmmds 

20 

4 

22 

5 

2 

2.5 

4. 1.3. 3 

Momentum  Mgmt 

14 

1.8 

16 

2.0 

1.5 

2.0 

4. 1.3.4 

Pointing  Mt.  Control 

21 

4.0 

26 

6 

5.0 

7.0 

4. 1 .3 .5 

Device  Mgmt 

10 

4 

15 

6 

2.5 

3.0 

4. 1.3.6 

Cmmd  I/F  Proc. 

15 

4 

16 

4.5 

3.0 

3.5 

128 

24.8 

151.2 

34.3 

139 

193 

TOTALS 

152.8 

185 

.5 

4.1.4  TRAFFIC  CONTROL  NOT  APPLICABLE  TO  PLATFORM 

4.1.4. 1 Comp/Prop  Const  State 

4. 1.4. 2 Manage  Const.  Orb  Man 

4. 1.4. 3 Sched . Deploy/Rendez . 

4. 1.4. 4 Manage  Rendezvous 

4. 1.4. 5 Target  Coll.  Avoid. 

4. 1.4.6  Cmmd  I/F  Proc. 

4.1.5  TRACKING  NOT  APPLICABLE  TO  PLATFORM 

4 . 1 . 5 . 1 Long  Range 

4 . 1 . 5. 2 Prox . 

4. 1.5.3  Object  Cat.  Main. 

4. 1.5.4  Tracking  Data  Cond . 

4. 1 .5.5  Device  Mgmt 

4. 1.5. 6 Cmmd  I/F  Mgmt 
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Table  6.9.8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 


GN&C  (Page  3 of  3) 


FUNCTIONS 


DATA 

MEMORY  (KBYTES)  

IOC  GROWTH  IOC 

PROG  DATA  PROG  DATA 


2. 5. 3. 3 OTV  Deployment/Ret.  NOT  APPLICABLE  TO  PLATFORM 


2. 5. 4. 3 OMV  Deployment/Ret  NOT  APPLICABLE  TO  PLATFORM 


GN&C  TOTAL 


370.1  468.1  190. 


PROCESSING 

(KOPSl 

GROWTH 


254.6 
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Table  6.9.8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
STRUCTURES/MECHANISMS 


DATA  PROCESSING 

FUNCTIONS  MEMORY  (KBYTES)  (KOPS) 

IOC  GROWTH  IOC  GROWTH 


prog" 

DATA 

PROG 

DATA 

2.3  STRUCTURES  & MECH  SUPPT 

4. 2. 3.1  Mechanism  Control 

2.8 

2.0 

5.6 

4.0 

0.4 

0.6 

4. 2. 3. 2 MRMS  Ups 

NOT  APPLICABLE 

TO  PLATFORM 

4. 2. 3. 3 Manage  Dock. /Berth. 

2.0 

1.6 

3.0 

2.0 

0.8 

1.6 

4. 2. 3. 4 Device  Mgmt 

4.0 

4.0 

8.0 

8.0 

0.2 

0.4 

4. 2. 3. 5 Cmmd  I/F  Proc 

5.0 

2.0 

°! 

<t\ 

8.0 

°l 

2J) 

13.8 

9.6 

20.6 

22 

2.4 

4.6 

TOTALS 

23 

.4 

42. 

6 

ECLS 

4.2.4  ECLSS  OPERATION  NOT  APPLICABLE  TO  PLATFORM 

4.2.4. 1 Control  Press/Atmos 

4. 2. 4. 2 Control  Temp/Hum 

4. 2. 4. 3 Potable  H^O  Mgmt 

4. 2. 4. 4 Grey  Water  Mgmt 

4. 2. 4. 5 Fire  Det.  & Control 

4. 2. 4. 6 Device  Mgmt 

4. 2. 4. 7 Cmmd  I/F  Proc . 
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Table  6.9.8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
CREUI  SYSTEMS  (Page  1 of  2) 

DATA  PROCESSING 

FUNCTIONS  MEMORY  (KBYTES)  (KOPS) 

IOC  GROWTH  IOC  GROWTH 

PROG  DATA  PROG  DATA 

4.3.1  HEALTH  MAINTENANCE  NOT  APPLICABLE  TO  PLATFORM 

4.3. 1.1  Crew  Phys.  Monitor 

4. 3. 1.2  Medical  Diag.  Supt. 

4. 3. 1.3  Treatment  Supt. 

4.3. 1.4  Nutrition  Anal. 

4.3. 1.5  Exercise  Planner 

4. 3. 1.6  Phys.  Data  Trans  & 

Anal . 


4.3.3  HABITABILITY  NOT  APPLICABLE  TO  PLATFORM 

4. 3. 3.1  Recreation  Services 

4 . 3 . 3 . 2 Crew/Grd  Comm 

4. 3. 3. 3 Cmmd  I/F  Proc 
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Table  6.9.8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
CREW  SYSTEMS  (Page  2 of  2) 


DATA  PROCESSING 

FUNCTIONS  MEMORY  (KBYTES)  (KOPS) 

IOC  GROWTH  IOC  GROWTH 

PROG  DATA  PROG  DATA 

4.3.4  EVA  SUPPORT  NOT  APPLICABLE  TO  PLATFORM 

4.3.4. 1 EMU  Contain  Control 

4. 3. 4. 2 EMU  Monitor/Maint . 

4. 3. 4. 3 EMU  Monitor/Maint. 

4. 3. 4. 4 Safety  Interlock  M/C 

4. 3. 4. 5 EVA  Real  Time  M/C 

4. 3. 4. 6 EVA  Visual  Info. 

4. 3. 4. 7 Airlock  Atmos  Pres. 

Composition  Control 

4. 3. 4. 8 Airlock  Temp/Hum 

4. 3. 4. 9 Device  Mgmt 

4.3.4.10  Cmmd  I/F  Proc 
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Table  6.9.8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 


FUNCTIONS 


COMM  & TRACKING  (Page  1 of  2) 


DATA  PROCESSING 

(KOPS) 

IOC  GROWTH 


PROG  DATA  PROG  DATA 


1.1  MANAGE  REAL  TIME  DATA  ACTION 

1.1.1  Acquire  Real  Time 

7 

21 

14 

42 

70 

100 

1.1.2  Prioritize  Real  Time 

2.8 

1.4 

5.6 

2.8 

7 

10 

1.1.3  Monitor  Real  Time 

3.5 

1.4 

5 

3 

14 

20 

1.1.4  Dispatch  Real  Time 

7 

3.5 

14 

7 

35 

50 

1.1.5  Format  Real  Time 

14 

__7 

_28 

_14 

_56 

80 

34.3 

34.3 

66.6 

68.8 

182 

260 

68 

.6 

135 

.4 

1.2  MANAGE  DELAYABLE  DATA  RETURN 

1.2.1  Acquire  Delayed  PL 

7 

150 

14 

300 

35 

50 

1.2.2  Prioritize  Delayed 

2.8 

1.4 

5.6 

2.8 

.7 

1 

1.2.3  Monitor  Delayed 

3.5 

1.4 

7 

2.8 

.98 

2 

1.2.4  Dispatch  Delayed 

7 

140 

14 

280 

24,5 

50 

1.2,5  Format  Delayed 

JLA 

7 

28 

14 

3.J> 

5 

34.3 

299.8 

68.6 

599.6 

64.68 

108 

334. 

1 

668. 

2 

4.2.5  COMMUNICATION 

4.2.5, 1 Network  Control 

20 

10 

30 

15 

small 

smal  1 

4. 2. 5. 2 Equipment  Control 

10 

10 

15 

15 

25 

35 

4. 2. 5. 3 Status  Monitor 

25 

15 

35 

25 

2 

3 

4. 2. 5. 4 Failure  Detection/R. 

25 

64 

50 

64 

10 

20 

4.2. 5.5  Cmmd  Prv/e 

5 

2 

5 

2 

10 

15 

4. 2. 5. 6 Interface  Control 

5 

2 

5 

2 

5 

6 

4. 2. 5. 7 Telemetry  Control 

5 

5 

5 

5 

200 

300 

95 

108 

145 

128 

252 

379 

203  273 


6-157 


Table  6.9,8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
COMM  & TRACKING  (Page  2 of  2) 


FUNCTIONS 

MEMORY 

(KBYTES) 

DATA 

PROCESSING 

(KOPS) 

IOC 

GROWTH 

IOC 

GROWTH 

PROG  DATA 

PROG  DATA 

2. 5. 3. 5 OMV  Status 

NOT  APPLICABLE  TO  PLATFORM 

(To  remote  customer) 


2. 5. 4. 6 OMV  Status  NOT  APPLICABLE  TO  PLATFORM 

(To  remove  customer) 


COMM  & TRACKING  TOTALS  605.7  1076.6  498.68  747 
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Table  6.9.8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 


INFORMATION 

DATA 

MANAGEMENT 

SYSTEM  (Paqe  : 

l of  4) 

DATA 

PROCESSING 

FUNCTIONS 

MEMORY 

(KBYTES) 

(KOPS) 

IOC 

GROWTH 

IOC 

GROWTH 

PROG  DATA 

PROG  DATA 

2.1 

Validate  PL  Cmmd 

4 20 

6 40 

0.01 

0.03 

24 

46 

2.2 

Check  SSDS  Serv.  Req . 
Restriction/Constraint 

20  50 

30  100 

1.7 

3 . 75 

70 

130 

2.3 

Validate  Core  Cmmd/Data 

. 1 

4 20 

6 40 

.01 

.03 

2.3.1  and  2.3.2 

.2 

10  25 

15  50 

.01 

.02 

14  45 

21  90 

59  111 


3.3  Develop  Ops  Event  Sched. 
3.3.1  to  3.3.4 


212  455  265  530  1.33 


667  795 


1.58 


3.4  Sequence  Operations 
3.4.1  to  3.4.4 


60  26  95  41  .2 


86  136 


.4 


4.3.2  Space  Station  Safety 
4.3.2. 1 to  4. 3. 2. 4 


15  3.5  25  11  small  small 


18.5  36 


4.3.5  OPS  & Procedure  Supt. 
4.3.5. 1 to  4. 3. 5. 5 


130  133  132  132  0.3 

263 


0.6 
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Table  6.9.8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
INFORMATION  DATA  MANAGEMENT  SYSTEM  (Page  2 of  4) 

DATA  PROCESSING 

FUNCTIONS  MEMORY  (KBYTES)  (KOPS) 

IOC  GROWTH  IOC  GROWTH 

PROG  DATA  PROG  DATA 


4.1.6  Time  & Frequency  Mgmt. 


4.1.6. 1 

Time  Source 

0.5 

0.2 

0.7 

0.3 

0.2 

0.3 

4. 1.6. 2 

Time  Update 

2 

0.5 

3 

1 

small 

small 

4. 1.6. 3 

Freq.  Source  Mgmt 

1 

0.3 

2 

0.5 

0.5 

0.7 

4. 1,6.4 

Device  Mgmt 

0.3 

0.1 

0.5 

0.2 

0.2 

0.3 

4. 1.6.5 

Cmmd  I/F  Proc . 

0.2 

0.1 

0.4 

0.2 

small 

small 

4.0 

1.2 

6.6 

2.2 

0.9 

1.3 

5.2  8.8 


5.1.1  Fit.  Data  Base  Mgmt. 


5. 1. 1. 1 

Update/Access  Synch 

250 

50 

500 

100 

.25 

.5 

5. 1.1.2 

Data  File  Mgmt. 

12 

140 

20 

200 

small 

small 

5. 1.1. 3 

Mass  Memory  Res.  Mgmt 

10 

4 

20 

10 

small 

small 

5. 1.1. 4 

Archival  Storage 

WOT  APPLICABLE 

TO  PLATFORM 

5.1. 1.5 

Device  Mgmt 

7 

0.4 

1.5 

0.7 

1 

1.5 

5. 1.1, 6 

Cmmd  I/F  Proc. 

0.7 

0.4 

1.5 

0.7 

0.  1 

0,2 

273. 

4 194.8 

543 

311.4 

1.35 

2.2 

468.2  854.4 
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Table  6.9.8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 


INFORMATION  DATA  MANAGEMENT  SYSTEM  (Page  3 of  4) 


DATA  PROCESSING 


FUNCTIONS  MEMORY  (KBYTES)  (KOPS) 


IOC 

GROWTH 

IOC 

GROWTH 

PROG 

DATA 

PROG 

DATA 

5.1.2  Fit.  Resource  Mgmt. 

5.1.2. 1 

Load  Scheduling 

4 

4 

8 

8 

small 

small 

5. 1.2. 2 

System  Executive 

570* 

1000* 

700* 

1300* 

% of 

% of 

- OPERATING  SYS.  (OS)* 

160 

250 

Application 

Application 

- Network  OS  (NOS)* 

410 

450 

100 

130 

5. 1.2. 3 

Initialized  Conf.  Cont 

30 

18 

50 

30 

small 

small 

5. 1.2. 4 

Configur.  Data  Proc. 

25 

65 

50 

100 

small 

small 

5. 1.2.5 

Facility  Status 

22 

60 

40 

80 

small 

small 

5. 1.2.6 

Recept.  Dist.  PL 

65 

140 

80 

160 

30 

50 

5. 1.2. 7 

Device  Mgmt. 

5 

10 

10 

15 

0.2 

0.33 

5. 1.2.8 

Cmmd  I/F  Proc 

12 

4 

20 

8 

0.5 

1.0 

163 

301 

258 

401 

30.7 

51.33 

464  659 

^5. 1.2.2  Excluded  from  5.1.2  total  because  OS  applies  to  memory 
configuration  and  NOS  is  contained  in  NIU. 

5.1.3  Displays  & Controls  NOT  APPLICABLE  TO  PLATFORM 

5. 1 . 3 . 1 Dev/ice  Mgmt 

5. 1.3.2  Cmmd  I/F  Proc 
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Table  6.9.8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
INFORMATION  DATA  MANAGEMENT  SYSTEM  (Page  4 of  4) 


DATA  PROCESSING 


FUNCTIONS  MEMORY  (KBYTES)  (KOPS) 


IOC 

GROWTH 

IOC 

GROWTH 

PROG 

DATA 

PROG 

DATA 

5 Monitor  & Status  System 

4.5.1  Monitor  Core 

2.4 

1.2 

4.8 

2.4 

0.3 

0.6 

4.5.2  Monitor  Customer 

2.4 

1.2 

4.8 

2.4 

0.25 

0.5 

4.5.3  Mass  Prop.  Conf. 

0.7 

0.3 

1.4 

0.6 

0.01 

0.02 

4.5.4  Diagnostic  Suppt. 

4.5.4. 1 

14 

14 

140 

140 

1.4 

14.0 

4. 5. 4. 2 

14 

14 

140 

28 

1.4 

2.5 

4. 5. 4. 3 

3.5 

1.4 

5.0 

2.8 

0.35 

0.50 

4.5.5  System  Test  & Eval 

14 

10 

28 

15 

0.7 

1.4 

4.5.6  Cmmd  I/F  Proc . 

20 

8 

60 

24 

1.2 

3.6 

71 

50.1 

384 

215.2 

5.61 

23.12 

121 . 

1 

599, 

,2 

IDMS  TOTALS 

2246 

3639 

.4 

42.11 

84.36 
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Table  6.9.8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 


PAYLOAD  AND  SERVICING  ACCOMMODATIONS  (Page  1 of  2) 


f 

FUNCTIONS 

MEMORY 

(KBYTES) 

DATA 

PROCESSING 

(KOPS) 

IOC 

PROG  DATA 

GROWTH 
PROG  DATA 

IOC 

GROWTH 

2.4  Provide  Ancillary  Data 

1.4  7 

2.1  14 

3 . 1 

6.3 

8.4 

16.1 

2.5  Support  Customer  Ops 
2.5.1  Customer  Data  Proc. 
2.5.2  Customer  PL  OPS 
2.5.3  Support  OTV  OPS 

2 . 5 . 3 . 1 OTV  Service 

2. 5. 3. 2 OTV  CO  & Diag 
2. 5. 3. 4 OTV  Operation 

100*  100*  100*  200*  0.08 

25  25  50  50  .03 

NOT  APPLICABLE  TO  PLATFORM 

.08 

.03 

W/O* 

50* 

365* 

2.5.4  Support  0 MV  OPS 

2.5.4. 1 OMV  Service 

2. 5.4. 2 OMV  CO  & Diag. 

2. 5. 4. 3 Remote  Ops  Co. 
2. 5. 4. 5 0 MV  OPS 

NOT  APPLICABLE  TO  PLATFORM 

2.5.5  Customer  Payload 
Checkout  Service 

25  1000 

30  1200 

small 

small 

1025 

1230 

2.6  SSPE  CO  AND  SERVICE 

100  1000 

100  1000 

small 

small 

1100 

1100 
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Table  6.9.8 

PLATFORM  TASK  1 FUNCTIONS  MAP  TO  REFERENCE  CONFIGURATION 
PAYLOAD  AND  SERVICING  ACCOMMODATIONS  (Page  2 of  2) 


DATA  PROCESSING 


FUNCTIONS 

MEMORY 

(KBYTES) 

(KOPS) 

IOC 

GROWTH 

IOC 

GROWTH 

PROG  DATA 

PROG  DATA 

4.4  Provide  Cust.  Avionic  Sev 

4.4.1  GN&C  Service 

4 . 4 . 1 . 1 Grd  Track 

3 1 

6 2 

0.5 

1 

4. 4. 1.2  Magnetic  Field 

1.5  0.5 

1.5  0.5 

0.3 

. 3 

4.4. 1.3  Pallet  Coarse 

10  2 

20  4 

10 

20 

4.4. 1.4  Relative  Align 

7 4 

10  6 

0.1 

0.  15 

21.5  7.5 

37.5  12.5 

10.9 

21.45 

29 

50 

4.4.2  Contamination  Control 

12  8 

24  16 

0.4 

0.8 

20 

40 

4.4.3  Tracking  Services 

NOT  APPLICABLE  TO  PLATFORM 

PAYLOAD  AND  SERVICING  ACC. 

TOTALS  2232.4  2801.1  14.51  28.66 
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7.0  GROUND  SSDS  DEFINITION 


7.1  Introduction  & Overview 

This  section  provides  the  preliminary  design  of  the  ground  Space  Station  Data 
System  (SSDS).  The  ground  program  elements,  the  allocation  of  functions  to 
the  elements  and  element  topology  are  presented  in  Section  7.2.  Section  7.3 
highlights  the  operational  data  flow  between  these  elements  for  selected  data 
types,  which  include  core  engineering  data,  payload  data,  uplink  command  data, 
and  Mission  Operations  coordination.  The  ground  SSDS  architecture  is 
presented  in  Section  7.4,  beginning  with  an  overview  of  the  system 
architecture  and  followed  by  subsections  devoted  to  the  more  detailed 
definition  and  architecture  of  each  of  the  elements. 

The  prime  inputs  used  to  develop  this  preliminary  definition  were: 

• Task  1 - Requirements  Definition 

• Task  2 - Options  Development 

• Task  3 - Trade  Studies 

• Langley  Mission  Data  Base  and  Woods  Hole  Data 

• Customer  Requirements  for  Standard  Services  from  the  Space  Station 
Information  System 

• Team  systems  engineering 

• NASA  guidance  and  feedback 

Supporting  options  and  trade  studies  include: 

• AI  options 

• Standardization/commonality  options 

• Communications  standardization  trade  study 

• Distributed  data  base  management  trade  study. 

• System  management  options 

• Command  and  resource  management  options  and  trade  study 

• Mass  storage  options  and  trade  study 

• Wide  area  processing  options 
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• Space  autonomy  and  function  automation  trade  study 

• Network  topology  trade  study 

The  primary  steps  of  the  ground  system  definition  process  include: 

General  buildup  from  Task  l's  data  flow  diagrams  and  functional  data 
sheets 

- Allocate  functions  to  space/ground  as  performed  in  the  Space  Autonomy 
and  Function  Automation  Trade  Study 

- Define  and  characterize  the  ground  elements  through  the  allocation  of 
functions  to  the  elements 

- Present  a ground  system  topology  and  architecture  that  connects  the 
elements 

- Document  the  system  definition  and  key  design  decisions  made  to  date 

A few  points  are  noteworthy  in  understanding  the  scope  of  the  ground 
definition  process.  The  first  is  that  wide  area  communications,  considered  an 
SSIS  institutional  service  outside  the  SSDS,  have  been  considered  only  to  the 
extent  necessary  to  determine  the  feasibility  of  the  proposed  designs. 

Another  point  is  that  the  system  is  sized  based  upon  mission  data  derived  from 
the  Langley  Data  Base  as  modified  by  the  Woods  Hole  Meeting.  In  many  cases, 
the  data  is  incomplete  and  requires  supporting  assumptions.  For  example,  peak 
data  rates  and  duty  cycles  alone  are  inadequate  to  ascertain  a true  data  flow 
rate  for  some  missions.  Consideration  of  the  interdependence  among  missions, 
observation  times,  and  data  delivery  times  is  required.  Core  traffic  has  also 
been  estimated  based  upon  approximate  requirements . The  assumptions 
associated  with  data  traffic  as  applied  to  the  ground  system  definition  are 
described  in  the  Network  Topology  Trade  Study.  However,  since  many  of  these 
assumptions  are  open  to  interpretation,  the  design  has  emphasized  system 
flexibility  in  order  to  accommodate  growth  and  changes  in  data  requirements . 

Finally,  it  is  important  to  note  that  each  element  of  the  ground  SSDS  is  in 
itself  a large  data  processing  system.  Therefore,  the  scope  of  this 
preliminary  definition  for  each  of  the  elements  has  been  limited  to  the 
definition  of  its  interfaces,  functions,  and  key  architectural  features . 
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7.2  Ground  System  Definition 


7.2.1  Summary  Of  Key  Assumptions  & Approaches 

The  following  major  assumptions,  and  design  decisions  were  made  with  respect 
to  programmatic  issues,  the  space  segment,  SISS  institutional  elements,  and 
intepretations  of  requirements . They  are  summarized  below  since  they  have 
major  impacts  on  the  system  concept. 

• the  KSA-R  downlink  will  operate  at  constant  rates  of  either  100  or 
300  Mbps  with  fill  data  added  onboard  as  required. 

• All  low  rate  payload  data  will  be  multiplexed  together  onboard  and 
will  be  sent  on  one  of  two  virtual  channels  (real  time  or  playback) 
on  the  KSA-R  link. 

• Each  high  rate  mission  will  be  allocated  one  virtual  channel  for  real 
time  and  one  virtual  channel  for  playback  data  on  the  KSA-R  link. 

• The  real-time  core  and  payload  engineering  (housekeeping)  data  will 
be  sent  on  the  SSA.  There  will  be  one  virtual  channel  each  for  core 
engineering  real-time  and  playback  data  and  one  virtual  channel  each 
for  payload  engineering  real  time  and  playback  data  (four  virtual 
channels  total).  The  Space  Element  will  be  identified  in  the  CCSDS 
Frame  (Spacecraft  ID).  If  customers  have  additional  needs  for  real 
time  core  and  payload  engineering  data,  it  must  be  included  in  their 
payload  stream. 

• Customers  will  be  able  to  receive  raw  real-time  data  at  any  time  it 
is  sent. 

• Data  stored  by  the  onboard  SSDS  or  C&T  system  will  be  played  back  in 
the  forward  direction  and  will  not  require  reversal. 

• All  core  and  payload  telemetry  and  telecommand  data  are  packetized, 
using  an  identical  bi-directional  CCSDS  packet  format.  All  packets 
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will  be  enclosed  within  bi-directional  CCSDS  frames.  Convolutional 
encoding  will  not  be  used.  All  low  rate  missions  will  be  Reed-Solomon 
(R-S)  encoded  in  CCSDS  codeblocks.  R-S  encoding  is  optional  for  high 
rate  missions  only. 

• Ancillary  data  will  be  provided  on-board  to  the  payloads,  with  the 
Engineering  Data  Centers  (EDCs)  acting  as  a backup.  NASA  will  not 
support  processing  of  ancillary  data,  but  rather  will  provide 
ancillary  data  in  a standard  form.  Per  the  customer  requirements , as 
reflected  in  Task  1,  if  the  standard  data  is  not  sufficient  for 
customer  needs,  more  accurate  or  non-standard  data  is  a customer 
responsibility . 

• Processing  is  provided  through  Level  0 for  all  missions  a3  a standard 
SSDS  service  for  all  packetized  data.  Data  will  be  returned  in  the 
form  it  was  when  given  to  the  onboard  DMS  or  C&T  system,  on  a 24  hour 
a day,  7 day  a week  availability. 

• It  is  acceptable  to  low  data  rate  customers  to  receive  their  data 
from  a Level  0 Processing  Facility. 

• Payload  Operations  Control  Centers  (POCC's)  will  not  perform  Level  0 
processing  and  will  obtain  Level  0 data  from  a Level  0 Processing 
Facility 

• Upper  level  processing  beyond  Level  0 will  be  supported  by  NASA  at 
Regional  Data  Centers  (RDC's)  but  is  not  a standard  SSDS  service. 

• All  Level  0 data  must  be  routed  to  an  RDC  for  upper  Level  processing. 
RDCs  are  required  to  receive  the  level  0 data  within  at  most  24 
hours,  as  specified  in  the  Langley  Mission  Database.  Missions  which 
specify  a data  delivery  delay  of  "0"  cannot  be  buffered,  but  must  be 
delivered  in  real-time. 

• POCC's  will  need  real-time  data  for  quick  look  analysis. 
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• As  described  in  Sections  4 and  7,3.3,  uplink  payload  data  including 
command  are  transparent  to  the  SSDS.  Uplink  payload  packets  are, 
therefore,  routed  directly  to  the  DHC  for  transmission  to  the  space 
element . 

• The  institutional  Space  Station  data  distribution  network  will  be 
augmented  to  support  transparent  switching  of  the  low  rate  data,  both 
payload  and  core,  using  standard  interfaces 

Additional  assumptions  are  listed  as  appropriate  in  the  subsections  below. 
These  assumptions  are  consistent  within  the  tasks  of  the  SSDS  Study,  but  are 
open  to  reasonable  debate.  Changes  in  some  of  the  above  may  have  a significant 
impact  on  the  ground  system,  as  described  in  the  Network  Topology  Trade  Study 
and  as  summarized  in  section  7.5. 

7.2.2  Definition  Of  Ground  System  Elements 

The  following  ground  Space  Station  program  elements  have  been  defined  as  a 
result  of  the  SSDS  study.  Some  of  these  elements,  such  as  Regional  Data 
Centers  (RDCs),  are  in  the  SSIS  but  are  listed  since  their  functions  have 
impacts  on  the  ground  system  concept.  The  proposed  locations  of  the  SSDS 
elements  are  described  in  the  Network  Topology  Trade  Study.  Changes  in  the 
definitions  and  assumptions  about  these  elements  may  impact  decisions  on  the 
overall  topology. 

7.2.2. 1 Data  Handling  Center  (DHC) 

The  Data  Handling  Center  serves  as  the  space/ground  gateway  between  the  TDRSS 
Ground  Terminals  (WSGT  and  NGT)  and  the  ground-to-ground  data  distribution 
network.  It  receives  and  buffers  data,  routes  virtual  channels  onto/from  the 
ground  network,  and  provides  uplink  service  authorization.  The  proposed  DHC 
location  is  at  White  Sands. 

7. 2. 2. 2 Ground  Services  Center  (GSC) 

The  Ground  Services  Center  (GSC)  provides  communication  and  common  resource 
coordination  for  the  ground  system.  It  serves  to  coordinate  the  scheduling  of 
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the  communication  and  ground  facility  resources  shared  among  the  Space 
Station,  COP,  and  POP  operations  control  centers.  These  shared  facilities 
include  the  Data  Handling  Center,  and  the  Level  0 Processing  Facilities.  The 
CSC  also  collects  status  information  from  the  shared  facilities  (outages,  data 
quality  monitoring,  etc)  and  prepares  reports  of  this  information  for  both 
customers  and  the  mission  scheduling  function  at  the  OCCs . The  CSC  also 
performs  SSIS  functions  involving  the  collection  of  information  on  customer 
usage  of  ground  system  elements  and  the  processing  of  customer  bills.  The 
proposed  CSC  location  is  at  GSFC. 

7. 2. 2. 3 Payload  Operations  Control  Centers  (POCCs) 

The  Payload  Operations  Control  Centers  (POCCs)  provide  ground  support  for  the 
operation  of  a single  payload  instrument  or  complement  of  instruments.  Control 
and  monitoring  POCC  functions  that  are  unique  to  the  payload  applications  are 
outside  the  boundaries  of  the  SSDS.  However,  the  POCC  functions  that  provide 
standard  services  — the  interfaces  to  the  DHC  and  the  GSC,  and  that  support 
ground  system  managment  are  within  the  SSDS.  POCCs  are  distributed  among  NASA 
centers,  RDCs,  and  customer  sites. 

7.2. 2.4  Regional  Data  Centers  (RDCs) 

Regional  Data  Centers  are  SSIS  elements  that  fall  outside  the  SSDS  boundaries, 
but  their  location  affects  the  SSDS  architecture . An  RDC's  basic  function,  as 
assumed  in  this  study,  is  the  support  of  higher  level  processing  and  archiving 
of  a single  scientific  discipline  or  group  of  related  disciplines  (at  each 
RDC)  . The  RDCs  receive,  analyze  (processing  above  Level  0)  and  archive  data 
from  many  sources,  including  space  entities  as  well  as  non-space  sources. 

Based  on  an  analysis  of  1997  mission  data  it  is  assumed  that  RDCs  will  be 
established  at  GSFC,  JPL,  LARC,  JSC,  and  MSFC  and  perhaps  at  customer  sites. 


7.2. 2.5  Level  0 Processing  Facilities  (LZPFs) 

These  facilities  remove  space-to-ground  artifacts  within  payload  data.  High 
data  rate  LZPFs  are  co-located  with  RDCs  at  GSFC,  JPL,  and  LARC.  A low  data 
rate  LZPF  is  centralized  at  GSFC  to  serve  the  other  RDCs  and  customers. 
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7. 2. 2. 6 Control  Centers  (CCs) 


The  Control  Centers  (CC3)  provide  ground  support  of  core  operations  throughout 
all  mission  phases,  including  man-tended  and  build  up,  as  well  as  back-up 
support.  These  centers  include  the  Space  Station  Operations  Control  Center 
(SSOCC),  the  Co-Orbiting  Platform  Control  Center  (COPCC),  and  the  Polar 
Orbiting  Platform  Control  Center  (POPCC),  The  SSOCC  is  located  at  JSC  and  the 
POP  and  COP  Control  Centers  are  located  at  GSFC. 

1 .2.2.1  Engineering  Data  Centers  (EDCs) 

The  Engineering  Data  Centers  (EDCs)  provide  archival  storage  of  Space  Station, 
COP,  and  POP  core  data  and  support  program  and  customer  requests  for  the 
retrieval  and  analysis  of  historical  data.  One  Engineering  Data  Center  is 
co-located  with  the  SSOCC  (at  JSC),  and  a second  EDC  is  co-located  with  the 
POP  and  COP  Control  Centers  at  GSFC. 

The  following  describe  important  generic  SSDS  functions  not  generally 
centralized  at  a specific  SSDS  facility. 

7. 2. 2. 8 Operations  Control  Network  (OCN) 

The  Operations  and  Control  Network  element  (OCN)  provides  networking  functions 
above  layer  3 of  the  ISO/OSI  model,  that  support  the  transparent  connection  of 
applications  at  the  various  NASA  centers.  It  provides  both  software 
downloading  control  functions  (linking  together  Control  Centers,  POCCs,  etc) 
as  well  as  Space  Station  Program  information  (for  customer  access)  and  is 
implemeted  through  a combination  of  commercially  available  ISO  type  software 
utilities  and  gateways  at  the  various  faciltiies. 

7. 2. 2. 9 Development,  Simulation,  Integration,  and  Training  (DSIT) 

The  Development,  Simulation,  Integration,  and  Training  (DSIT)  functions 
support  the  development  and  integration  of  new  or  modified  software, 
integration  of  customer  payloads,  end-to-end  communications  checkout,  crew  and 
ground  controller  training,  and  construction  of  simulation  models  for  use  at 
remote  sites.  While  the  DSIT  is  defined  as  a program  element,  it  is  recognized 
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that,  similar  to  the  Customer  Interface  Element  (CIE)  functions,  defined  in 
7.2.2.10  below,  the  DSIT  functions  will  be  distributed  throughout  the  ground 
system  and  that  elements  of  the  DSIT  will  appear  at  each  control  center,  LZPF , 
RDC,  and  facility  that  involves  software  development  and  simulation.  A major 
part  of  this  element,  the  Software  Support  Environment  (SSE),  is  described  in 
Section  8.2. 

7.2.2.10  Customer  Interface  Elements  (CIEs) 

Customer  Interface  Elements  (CIEs)  provide  a standard  interface  to  customers 
and  a connection  between  the  customer  and  the  services  of  the  Space  Station 
Program.  The  elements  allow  a customer  to  "dial  in"  to  a NASA  location  (RDC, 
POCC,  etc),  access  a menu-driven  interface  describing  the  services  of  the 
Space  Station  Program  (scheduling,  archival  data  catalogs,  etc)  and  be 
connected  via  the  Control  Network  to  a selected  service.  The  actual  service 
might  be  local  to  that  center  or  it  might  be  located  at  another  location. 
Specific  functions  accessed  by  this  single  point  of  Customer  Contact  to  SSP 
Services  include: 

- Logon/Authorization  to  access  SSIS  Services 

- Communication  and  common  services  coordination  (access  to  GSC) 

— Space  Station  Program  Databases  (Authorization  and  transparent  access) 

- Control  Center  services  (Access  to  Scheduling) 

- Archival  data  catalog  services 

- Uplink  Access  (Access  to  DHC) 

TMIS  Interface 

- Bulletin  boards  and  electronic  mail  for  sharing  information  among 
users  and  with  the  Space  Station  program 

While  the  CIE  is  defined  as  a program  element,  it  is  recognized  that  the 
foregoing  functions  are  actually  distributed  throughout  the  ground  system  and 
that  CIE  functions  will  appear  at  each  NASA  center.  A detailed  design  for  this 
element  is  therefore  not  shown.  The  implementation  of  these  functions  should 
present  an  identical  interface  to  customers  no  matter  which  NASA  center 
implements  them. 
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7.2.3  Partitioning/Allocation  of  Functions  to  Elements 


Table  7. 2. 3-1  maps  the  lower  level  functional  requirements,  which  were  derived 
during  Task  1 of  the  SSDS  A/A  Study,  to  the  ground  elements.  The  tracing  from 
the  2-digit  level  function  is  shown  for  completeness.  Tracing  back  to  Task  1 
source  requirements  is  provided  in  the  Task  1 report.  In  many  cases  only  a 
subset  of  the  lowest  level  functions  of  a given  portion  of  the  function  list 
are  implemented.  This  is  especially  true  for  the  Control  Centers  which  provide 
support  and  back-up  to  the  onboard  functions.  The  strawman  locations  of  the 
SSDS  elements  are  shown  on  Table  7. 2. 3-2. 

7.3  Key  Operational  Features 

The  purpose  of  this  section  is  to  describe  data  flow  between  the  various 
ground  elements  defined  in  Section  7.2 

7.3.1  Core  Engineering  Data  Management 

The  SSDS  provides  core  operations/administrative  data  to  support  the  ground 
operations  associated  with  the  payloads  and  the  core  systems.  The  ground 
flow  of  core  engineering  data  is  depicted  in  figures  7.3. 1-1  and  7.3. 1-2. 

7. 3. 1.1  Payload  Operations  Support 

The  onboard  SSDS  provides  time-stamped  core  engineering  ancillary  data  to  the 
payloads.  The  data  is  provided  in  standard  engineering  units,  and  any 
reformatting/ref inement  of  the  data  is  a customer  responsibility.  The  payload 
incorporates  the  ancillary  data  into  its  payload  CCSDS  packets,  which  are 
downlinked  and  distributed  to  the  Level  Zero  Processing  Facilities  and 
POCC/customer  facilities.  (See  Section  7.3.2  for  a more  detailed  discussion 
of  payload  data  management.)  Thus,  the  ancillary  data  required  for  the  ground 
control  of  the  payload  and  for  production  data  set  generation  is  contained 
within  the  payload  packets. 

The  SSDS  also  provides  a non-real-time  service  of  electronic  access  to  the 
core  engineering  data  archives,  which  are  contained  within  the  EDC,  for  the 
retrieval  of  historical  data. 
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Table  7. 2. 3-1 

Ground  Element  Function  Allocation 


Element 


Functions 


Data  Handling 
Center  ( DHC) 


Low  & High  Rate 
Level  0 Processing 
Facilities  ( LZPFs) 


Level  0 Processing 
Facility  (LZPFs) 


1.1  Manage  Real  Time  Data  Return 

1.1.4  Dispatch  Realtime  Data 

(reqs  5. 3. 1.1. a, b) 

1 .3  Data  Distribution 

1.3.1  Preprocessing  (Frames)  1.3.2  Data 
Capture  (Bulk  Record) 

1.3.3  Routing  & Transmission 

1.3.4  Quality  Verification 

2.1  Validate  Payload  COmmands/Data 

2.1.1  Authorized  User 

2.1.2  Authorized  Address 


2.3  Validate  Core  Commands/Data 
2.3.1  Authorize  Operator 


5.2  Manage 

5.2.1 

5.2.2 

5.2.3 

5.2.4 

5.3.5 

5.2.6 


Ground  System  Facilities 
Interface  Management 
Schedule/Status  Compare 
Transmit  Reconfiguration  Schedule 
Ground  Status  Database  Management 
Adjust  For  Unscheduled  Mode  Change 
Displays  & Controls 


1 .1 


Manage  Real  Time  Data  Return 
1.1.4  Dispatch  Realtime  Data 
(reqs  5. 3. 1.1. a, b) 


1 .4  Manage 

1.4.1 

1.4.2 

1.4.3 

1.4.5 

1.4.6 

1 .4.7 


Deliverable  Customer  Data 
Customer  Data  I/F  Mgt 
Customer  Data  Capture 
Customer  Data  Handling 
Level  0 Customer  Data  Processing 
Customer  Data  Accounting 
Routing  & Transmission 


5.2 


Manage  Ground  System  Facilities 

5.2.1  Interface  Management 

5.2.2  Schedule/Status  Compare 

5.2.3  Transmit  Reconfiguration  Schedule 

5.2.4  Ground  Status  Database  Management 

5.3.5  Adjust  For  Unscheduled  Mode  Change 

5.2.6  Displays  & Controls 
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Element 


Ground  Services 
Center  (GSC) 


Control  Centers 


Table  7. 2. 3-1 

Ground  Element  Function  Allocation 


(CCs) 


Functions 


7.2 

5.2 


Log  Customer  Usage  Of  System 
Manage  Ground  System  Facilities 

5.2.1  Interface  Management 

5.2.2  Schedule/Status  Compare 

5.2.3  Transmit  Reconfiguration  Schedule 

5.2.4  Ground  Status  Database  Management 

5.3.5  Adjust  For  Unscheduled  Mode  Change 

5.2.6  Displays  & Controls 


1 .5  Manage 

1.5.1 

1.5.2 

1.5.3 

1.5.4 


Deliverable  Core  Data 
Core  Data  Interface  Management 
Core  Data  Capture 
Data  Extraction 
Displays  & Controls 


2.5  SupportCustomerSystem  Operation 

2.5.3  Support  OTV  Operations 

2. 5.3.4  OTV  Operation 

2.5.4  Support  OMV  Operation 

2. 5. 4. 5 OMV  Operation 

2. 5. 4. 6 OMV  Status  Report 


3.1 


Develop  Recurring  Operations  Masters 

3.1.1  Develop  Normal  Day  Payload  Operations 

3.1.2  Develop  Normal  Day  Space  Operations 

3.1.3  Identify  Potential  Conflicts 

3.1.4  Develop  Major  Event  Payload  Operations 


3.2  Develop  Short  Term  Schedules 

3.2.1  Confirm  Payload  & Core  Schedules 

3.2.2  Incorporate  New/Revised  Operations 

3.2.3  Check  For  Conflicts 

3.2.4  Check  For  Facilities  Capabilities 

3.2.5  Resolve  Conflicts 

3.2.6  Check  Unresolved, 

Restrlcted/Constralnted  Commands 

3.2.7  Maintain  Short  Term  Schedules/Develop 
Operating  Events  List 


4.1  Operate  GN&C  Systems 

4.1.1  Navigation 

4. 1.1.1  Space  Station  State/Orbit 
Determination 

4. 1.1. 7  Command  Interface 
Processing 
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Table  7. 2. 3-1 

Ground  Element  Function  Allocation 


Element 


Control  Centers  (CCs) 
(Cont) 


Functions 


4.1 .2 


4.1.3 


4.1.4 

4.1 .5 

4.1 .6 


Guidance 

4. 1.2.1  Reboost/Reentry  Targeting 
4. 1.2. 7 Command  Interface 

Processing 
Attitude  Control 

4. 1.3.1  Control  Attitude 
& Translation 

4. 1.3. 2 Maneuver  Coordination 

4. 1.3. 3 Momentum  Mgt 

4. 1.3. 4 Pointing  Mount  Control 

4.1 .3.5  Device  Mgt 

4. 1.3. 6 Command  I/F  Processing 
Traffic  Control 

4. 1.4. 5 Target  Collision  Avoidance 

4. 1.4. 6 Command  I/F  Processing 
Tracking 

4. 1.5. 6 Command  I/F  Processing 
Time  & Frequency  Mgt 

4. 1.6. 5 Command  I/F  Processing 


4.2  Operate  Non-GN&C  Systems 

4.2.1  Operate  Power  System 

4. 2. 1.7  Command  I/F  Processing 

4.2.2  Operate  Thermal  Control  System 

4. 2. 2. 4 Command  I/F  Processing 

4.2.3  Structures  & Mechanism  Support 

4. 2. 3. 5 Command  I/F  Processing 

4.2.4  ECLSS  Operation 

4. 2. 4. 7 Command  I/F  Processing 

4.2.5  Communication 

4. 2. 5. 5 Command  Processing 

4.3  Support  Flight  Crew  Activities 

4.3.1  Health  Maintenance 

4. 3. 1.2  Medical  Diagnostic 

4. 3. 1.3  Treatment  Support 

4. 3. 1.7  Command  I/F  Processing 

4.3.2  Space  Station  Safety 

4. 3.2.1  Caution  & Warning 

4. 3. 2. 2 Abnormal  & Emergency 
Procedures 

4. 3. 2. 4 Command  I/F  Processing 

4.3.4  EVA  Support 

4.3.4. 5 EVA  Real  Time  Monitor  & 
Control 

4.3.4.10  Command  I/F  Processing 
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Table  7. 2. 3-1 

Ground  Element  Function  Allocation 


Element 


Control  Centers  (CCs) 
(Cont) 


Engineering  Data 


Functions 


4.4  Provide  Customer  Avionics  Services 
4.4.3  Tracking  Services 


4.5  Monitor  & Status  System 

4.5.3  Mass  Properties  Configuration  Update 

4.5.4  Diagnostics  Support 

4. 5.4.1  Fault  Analysis 

4. 5. 4. 2 Fault  Correction 

4. 5.4.3  Trend  Analysis 
4.5.6  Command  I/F  Processing 


5.1  Manage  Flight  System  Facilities 

5.1.1  Flight  Data  Base  Mgt 
5. 1.1. 2 Data  File  Mgt 

5. 1.1. 6 Command  I/F  Processing 

5.1.2  Flight  Resource  Mgt 

5. 1.2. 8 Command  I/F  Processing 


5.2 


Manage  Ground  System  Facilities 

5.2.1  Interface  Management 

5.2.2  Schedule/Status  Compare 

5.2.3  Transmit  Reconfiguration  Schedule 

5.2.4  Ground  Status  Database  Management 

5.3.5  Adjust  For  Unscheduled  Mode  Change 

5.2.6  Displays  & Controls 


1.4  Manage  Deliverable  Customer  Centers  (EDCs) 
Data 

1.4.4  Ancillary  Data  Acquisition 


1.5  Manage  Deliverable  Core  Oata 

1.5.5  Engineering  Data  Analysis 

1.5.6  Core  Data  Accounting 


5.2  Manage 

5.2.1 

5.2.2 

5.2.3 

5.2.4 

5.3.5 

5.2.6 


Ground  System  Facilities 
Interface  Management 
Schedule/Status  Compare 
Transmit  Reconfiguration  Schedule 
Ground  Status  Database  Management 
Adjust  For  Unscheduled  Mode  Change 
Displays  t*  Controls 
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Table  7. 2. 3-2 

Proposed  Locations  Of  Elements 
(Based  on  1997  Mission  Data  Base) 


Element 

Proposed  Location 

Data  Handling  Facility 

White  Sands 

Level  0 Processing  Facility 
(Low  Rate) 

Goddard  Space  Flight  Center 

(High  Rate) 

GSFC,  JPL,  LARC 

Space  Station  Operations 
Control  Center 

Johnson  Space  Center 

Co-Orbiting  Platform 
Control  Center 

Goddard  Space  Flight  Center 

Polar  Orbiting  Platform 
Control  Center 

Goddard  Space  Flight  Center 

Engineering  Data  Centers 

1)  Johnson  Space  Center 

2)  Goddard  Space  Flight  Center 

Payload  Operations  Control 
Centers  (SSIS) 

Distributed 

Regional  Data  Centers  (SSIS) 

Goddard  Space  Flight  Center 
Jet  Propulsion  Laboratory 
Langley  Research  Center 
Johnson  Space  Center 
Marshall  Space  Flight  Center 

This  design  approach  offers  the  customer  the  advantage  of  immediate 
availability  of  the  time-homogeneous  ancillary  data  required  for  payload  data 
processing  and  payload  control.  Other  approaches,  such  as  the  obtaining  of 
ancillary  data  from  a ground  replication  of  the  onboard  database,  have  the 
potential  for  imposing  delays  in  the  delivery  of  the  data.  Also,  the  problems 
associated  with  the  provision  of  the  data,  be  it  through  queries,  broadcasting 
of  data  sets,  etc.,  are  the  same  whether  they  are  to  be  solved  onboard  or  on 
the  ground.  A ground-oriented  approach  adds  the  complexity  of  managing  the 
replication  of  the  birthsite,  onboard  database  to  satisfy  the  requirements  of 
the  payload  users  and  is  recommended  only  if  the  proposed  approach  proves 
infeasible  due  to  onboard  processing  or  bandwidth  limitations. 
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ssocc 


© May  Be  Remotely  Located; 
Logical  Flow  Indicated 

© Provides  Near-Real-Time 
Status  Data  to  Other 
Control  Centers  During 
Joint  Operations 


Figure  7.3.1-1.  Real-Time  Core  Engineering  Data  Flow 


Space  Station  Core  Data 
P/F  Core  Data 

Payload  Data  (Merged  Ancillary  Data) 

Backup  Routing  (During  Primary 
EDC  Failure) 
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7. 3. 1.2  Core  Operations  Support 

Core  operations/administrative  data  packets  to  support  the  Space  Element's 
core  ground  operations  are  downlinked  within  dedicated  virtual  channels  (one 
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real-time  and  one  playback  ) within  the  SSA  return  link.  The  DHC  routes 
these  channels  to  the  appropriate  (JSC  for  Space  Station  and  GSFC  for 
platform)  NASA  Center  gateway.  At  the  gateway,  the  packets  are  extracted 
and,  based  upon  the  application  ID,  routed  to  the  appropriate  node(s). 

These  nodes  include  the  Control  Center/Mission  Scheduling,  the  EDC,  and  other 
Ground  Services. 

Packets  containing  core  engineering  (Space  Element  status)  data  are  routed  to 
the  Control  Center  and  the  EDC.  The  Control  Center  utilizes  the  data  for  its 
core  operation's  monitoring  and  control  functions.  It  also  extracts  Space 
Element  status  and  incorporates  it  into  operations  messages  which  it  sends  to 
other  Control  Centers  involved  in  joint  operations  and  to  supporting 
institutional  facilities  (e.g.  the  Flight  Dynamics  Facility  for  platform 
support) . 

The  EDC  creates  and  manages  the  full-rate  full— sample  core  engineering 
database.  It  serves  the  Control  Center  and  the  Space  Element  as  the  highest 
priority  users  for  the  retrieval  of  core  data  sets,  report  generations,  and 
common  data  analyses  (e.g.  plots).  There  are  two  EDC's,  and  they  each 
provide  a limited  backup  of  the  other's  functions.  In  the  event  of  the 
failure  of  a Control  Center's  primary  EDC,  data  destined  for  the  failed  EDC 
is  routed  to  the  alternate  EDC.  The  alternate  EDC  stores  the  data  and 
services  requests  from  the  failed  EDC's  Control  Center  and  Space  Element. 

The  available  data  sets  are  limited  to  those  acquired  since  the 
failure-induced  handover.  The  alternate  EDC  continues  to  provide  its  normal 
services,  though  it  may  reprioritize  the  requests.  Upon  recovery,  the 
primary  EDC  requests  the  transfer  of  its  saved  data  sets  from  the  alternate 
EDC. 


The  ground  system  flexibility  is  also  dependent  upon  the  amount  of 
preprocessing  which  is  required  (and  which  would  have  to  be  duplicated)  to 
render  the  core  engineering  data  useful  to  the  EDC's  and  Control  Centers.  It 
is  assumed  the  onboard  system  provides  data  with  the  following  attributes: 

— forward  direction,  no  reversal  required 

— engineering  units  (level  1A),  no  PCJi  calibrations  required 
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— - stable  formats,  air/ground  communicated  formats,  or  formats  that  are 

defined  by  data  contents  (e.g.  parameter  ID's  and  pointers  contained 
within  the  data),  no  offline  reconf iguration  processes  required 
— groupings  by  subsystem,  minimal  sorting  required  for  inclusion  into  a 
database  manager. 

Packets  containing  Space  Station  service-oriented  data  messages  are  also 
managed  by  the  JSC  gateway.  The  gateway  processing  may  include  a service 
manager  that  provides  protocol  conversion  and  message  routing  between  the 
air-to-ground , CCSDS  format  and  the  ground  distribution,  ISO  format.  It  is 
assumed  that  there  is  an  onboard  service  manager,  analogous  to  the  ground 
service  manager,  that  manages  the  service-oriented  messages.  The  extent  of 
the  managers 1 processing  is  dependent  upon  the  compatibility  of  the  CCSDS  and 
ISO  formats  and  the  ability  of  the  addressed  services  to  handle  the  two 
formats.  Source  and  destination  identifiers  within  the  CCSDS  format  would 
simplify  the  role  of  the  service  managers,  since  the  services  support 
multiple  users  and  any  user  can  choose  among  multiple  services.  An  example 
is  a scenario  where  a crewperson  at  an  MPAC  wants  interactive  access  to  one 
of  the  ground  services,  such  as  archival  data  query/retrieval . For  roundtrip 
routing,  both  the  user's  MPAC  and  the  archive  must  be  uniquely  identified.  A 
multitude  of  ID's  may  be  required  to  provide  unique  mappings  for  all 
possible  combinations  or  application-level  processing  (service  managers)  of 
the  packet  data  fields  is  required  to  determine  the  routing.  A similar 
problem  exists  for  space/ground  inter— processor  communications. 

7.3.2  Payload  Data  Mangement 

Payload  data  procesing  will  impose  the  greatest  burden  on  the  SSDS;  the  high 
data  rates  and  rapid  delivery  requirements  establish  a significant  technology 
demand  on  the  ground  system.  Payload  data  flow  is  depicted  in  Figure  7. 3. 2-1. 

As  mentioned  in  Section  7.2.2,  all  low  rate  mission  payload  data  (less  than  10 
Mbps)  will  be  multiplexed  together  onboard  and  will  be  sent  on  one  of  two 
virtual  channels  (real  time  or  playback)  on  the  KSA-R  link;  and  each  high  rate 
mission's  payload  data  will  be  allocated  one  virtual  channel  for  real  time  and 
one  virtual  channel  for  playback  on  the  KSA-R  link.  In  addition,  a predefined 
subset  of  core  ancillary  data  will  be  embedded  into  the  payload  packets  for 
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2 Virtual  Channels  for  Each  High-Rate  Payload  (1  R/T,  1 PLBK) 

2 Virtual  Channels  for  Composite  Low-Rate  Payload  (1  R/T,  1 PLBK) 


To  POCCs 
(Real  Time) 


To  RDCs 

(Upper  Level  Proc) 


To  POCCs 
(Real  Time) 


To  RDCs 

(Upper  Level  Proc) 


SSA 

2 Virtual  Channels  for  Core  Engineering  (1  R/T,  1 PLBK) 

2 Virtual  Channels  for  Composite  Payload  Engineering  (1  R/T,  1 PLBK) 


Figure  7.3. 2-1.  Payload  Data  Flow 


use  in  real  time  quicklook  functions  at  POCC's  and/or  upper  level  processing 
functions  at  RDCs.  All  payload  engineering  data  will  be  allocated  one 
virtual  channel  for  real  time  and  one  virtual  channel  for  playback  on  the  SSA 
channel.  The  DHC  at  White  Sands  performs  the  frame  synchronization  for  all 
channels  and  removes  fill  frames. 

Each  frame  synchronizer  has  a Reed-Solomon  Error  Correction  Decoder  and  all 
data  from  the  frame  sync  is  fed  to  it.  If  the  decoding  is  successful,  the 
data  is  assumed  to  be  R-S  encoded,  it  is  so  tagged,  and  all  further  processing 
occurs  on  the  corrected  data.  If  the  decoding  is  unsuccessful,  it  is  so 
tagged,  and  processing  is  done  on  the  uncorrected  data.  This  is  done  on  a 
frame-by-frame  basis  so  that  some  virtual  channel  may  be  encoded  and  others 
not.  Subsequent  to  this  correction  and  check,  the  virtual  channels  are 
identified,  separated  and  virtual  channel  accounting  begun.  The  Processing, 
Accounting,  Quality  Monitoring  and  Fault  Isolation  Functions  can  be  accessed 
by  RDCs,  POCCs  and  independent  users. 

The  level  0 processing  would  then  be  performed  either  at  the  low  rate  LZP 
facility  located  within  GSFC  or  at  high  rate  LZP  facilities  collocated  at 
RDCs.  This  process  consists  of  packet  reordering  and  gap  filling  to  create 
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contiguous  data  sets  on  a pay load-by -pay  load  basis.  The  real-time  data  will 
be  packet  routed  to  POCC's  for  quicklook  purpose  as  needed. 

Processing  of  payload  data  beyond  level  zero  processing  is  outside  the 
boundaries  of  the  SSDS  and,  therefore,  not  discussed  here. 

Payload  Data  Traffic  is  provided  in  Figure  7. 3. 2-2  and  is  based  on  the  Langley 
Data  Base  for  the  year  1997. 

7.3.3  Uplink  Command  Data  Management 

In  order  to  understand  the  ground  topology  for  the  flow  of  uplink  command 
data,  it  is  important  to  understand  the  end-to-end  design  for  command 
management.  This  design  is  presented  in  Section  4.  Table  7. 3. 3-1  summarizes 
the  command  management  functions  of  each  of  the  ground  elements  and  provides 
reference  to  the  sections  that  define  these  functions  in  greater  detail. 

The  design  feature  which  drives  the  ground  SSDS  topology  is  the  transparent 
handling  of  the  payload  command  data.  Since  the  SSDS  performs  no  checks  on 
the  payload  commands,  there  is  no  requirement  that  they  be  routed  through  the 
Control  Center.  The  uplink  payload  command  packets  generated  at  POCC's  and 
customer  facilities  are  routed  directly  to  the  ground/space  gateway,  the 
Data  Handling  Center. 

Uplink  core  command  packets  generated  at  the  Control  Centers  are  also  routed 
to  the  DHC . It  is  not  necessary  that  COP  core  command  packets  be  routed  via 
the  SSOCC. 

The  DHC  maintains  a log  of  received  packets,  collects  the  packets  and  frames 
them  in  accordance  with  the  CCSDS  formats.  Encryption  of  the  uplink  frames 
for  transport  to  the  Space  Element,  if  required  by  the  Space  Station  Program, 
would  also  be  a DHC  re; ponsibility . 

The  flow  of  uplink  command  data  is  depicted  in  figure  7. 3. 3-1. 
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Table  7. 3. 3-1 

Command  Data  Management  Functions  Map 
To  Ground  Elements 


ELEMENT 

Control  Center 


Engineering  Data 
Center 


POCC's  or 
Independent 
Customers ' 
Facilities 


Data  Handling 
Center 


FUNCTIONS 

Mission  Scheduling 

t Development/Maintenance  of  Mission 
(P/L  and  Core)  Operations/Attributes 
Database 

• Development/Maintenance  (Change)  of 
Operating  Events  Schedule 

Mission  Operations:  Core  Cmd-Management 

• Operator  Authorization 

• Access  Control  to  Command  Sets  and 
Software  Loads 

• Command  Generation 

• Command  Validation 

- Safety 

- Effectlvlty 

- Schedule  Compliance 

- Etc. 

• Verification  of  Receipt/Execution 

• Management  of  Two-Stage  and  Stored 
Program  Command  Sequences 

• CCSDS  Telecommand  Packet  Build 

Capture  and  Archival  Storage  of 
Command  Data 

• Uplinked  Telecommands 

• Downlinked  Command  Logs 

Payload  Operations:  Payload  Cmd.  Mgmt. 

• Payload-Specific  Functions 
Analogous  to  those  performed  by  the 
Control  Center  for  Core  Commands: 

- Operator  Authorization 

- Access  Control  to  Command  Sets 

- Command  Generation 

- Command  Validation 

- Verification  of  Receipt/Execution 

- Management  of  Stored  Program 

- Command  Sequences 

• CCSDS  Telecommand  Packet  Build 

Ground/Space  Gateway  Management 

• POCC  and  Customer  LOGON 

• Uplink  Authorization 

• CCSDS  Frame  Build 

• CCSDS  TC  Transfer  Layer  Services 


REFERENCE 

SECTION 


7. 4. 6. 2. 6 


7. 4. 6. 2. 2, 
7. 4. 6. 2. 4, 
7. 4. 6. 2. 5 


7. 4. 7.1, 


None  (Ground 
SSIS  functions 
listed  for 
completeness) 
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7. 3. 3.1  Payload  Uplink  Command  Data  Management 

Payload  uplink  packets  can  be  issued  from  customer  facilities  and  POCC's 
distributed  throughout  the  ground  system. 
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In  order  to  issue  uplink  packets,  the  customer  or  POCC  logs  on  to  the  Data 
Handling  Center.  LOGON  includes  providing  a password  ID.  POCC's  providing 
continuous  support  can  remain  logged  on  to  the  DHC.  As  an  optional  service, 
the  user  can  request  a schedule  report  containing  information  on  his 
scheduled  payload  activities  and  information  of  general  interest,  e.g 
trajectories  or  TDRSS  communication  timelines.  The  report  is  requested  from 
the  Control  Center's  Mission  Scheduling  System  which  routes  it  to  the  user. 
The  user  can  also  request  connection  with  the  Mission  Scheduling  System  to 
negotiate  schedule  changes. 

After  LOGON,  the  customer/POCC  creates  uplink  CCSDS  packets  which  are  routed 
via  the  ground  network  to  the  DHC.  The  DHC  performs  an  uplink  authorization 
check  on  each  of  the  packets  by  checking  the  application  (destination)  ID  vs. 
a table  listing  the  ID's  which  this  source,  the  customer  or  POCC,  is 
authorized  to  address.  The  authorization  table  is  created  prior  to  the 
mission  and  is  controlled  by  the  Ground  Services  Center  (GSC) . Packets 
which  successfully  pass  this  check  are  input  to  the  frame  build  process.  The 
payload  frames  are  uplinked  on  the  TDRSS  KSA-F  link.  Packets  which  fail  the 
uplink  authorization  check  are  rejected,  and  notifications  are  sent  to  the 
customer/POCC  and  to  the  GSC  communications  security  monitoring  function. 

Provision  of  additional  privacy/security  measures,  e.g.  encryption  of  the 
command  data,  is  a customer/POCC  responsibility.  The  SSDS  only  requires  that 
the  header  information  remain  clear. 

7. 3. 3. 2 Core  Uplink  Command  Data  Management 

Core  uplink  CCSDS  packets  are  issued  from  the  Control  Center.  They  are 
routed  over  the  NASA  Center  Network,  and  the  Engineering  Data  Center 
captures  and  archives  the  packets.  From  the  Center's  gateway  the  packets  are 
routed  to  the  Data  Handling  Center,  where  they  are  built  into  CCSDS  frames 
for  transmission  on  the  TDRSS  SSA-F  link. 

The  Control  Center  is  continuously  logged  on  to  the  Data  Handling  Center.  A 
threat  analysis  is  necessary  to  determine  the  security  measures  required  for 
the  Control  Centei — to-DHC  link.  Encryption  of  the  packet  data  fields,  if 
required,  would  be  a function  of  the  NASA  Center  gateway. 
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7.3.4  Mission  Operations  Coordination 


This  section  describes  the  flow  of  schedule  and  status  data  throughout  the 
Aground  SSDS  in  support  of  mission  operations.  The  end-to-end  design  for 
system  control/management  is  presented  in  Section  4.4.  Table  7. 3. 4-1 
summarizes  the  mission  coordination  functions  of  each  of  the  ground  elements 
and  provides  reference  to  the  sections  that  define  these  functions  in  greater 
detail . 

Figure  7. 3. 4-1  depicts  the  interfaces  for  the  flow  of  schedule  and  status 
data  and  the  general  order  of  precedence  for  schedule  generation  and  status 
reporting.  In  general,  the  order  reflects  the  hierarchical  nature  of  the 
controlling  elements.  Each  element  provides  to  lower  level  elements  the 
scheduling  and  status  information  required  to  perform  their  functions  and 
receives  from  them  only  the  status  information  which  can  impact  the  higher 
level  schedule. 

Considering  the  many  interfaces  required  for  mission  coordination,  the 
standardization  of  the  SSP  scheduling  and  status  reporting  systems  is  highly 
desirable.  Commonality  is  particularly  needed  between  the  Space  Station  and 
Platform  Mission  Scheduling  Systems  considering  the  number  of  elements  and 
customers  which  may  require  interfaces  to  both  systems. 

The  types  of  schedule  and  status  information  required  for  mission 
coordination  break  into  two  basic  categories:  operations  and  communications. 

7.3.4. 1 Mission  Operations 

Mission  operations  information  includes  the  scheduling  and  statusing  of  the 
mission  activities.  Mission  scheduling  is  a function  of  the  centers 
controlling  the  Space  Elements,  The  hierarchy  among  the  control  centers  is: 

— STS  MCC 
— Space  Station  OCC 

- Platform  OCC 
— POCC 

~ OMV/OTV  Remote  Operations  CC 

- Free  Flyer  OCC 
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Table  7. 3. 4-1 

Mission  Coordination  Functions  Map 
to  Ground  Elements 


ELEMENT 

FUNCTIONS 

REFERENCE 

SECTION 

SSOCC 

Space  Station  Mission  Scheduling/Status 

7. 4. 6. 2. 6 

• P/L  Modes 

• Onboard  Core  Operations 

• Proximity  Operations 

• Ground  Resources 

SSOCC  Facility  Management 

7. 4. 6. 2. 5 

COPCC/POPCC 

• Interface  to  SS  Mission  Scheduling 

• Interface  to  GSC  Comm.  Status 

Platform  Mission  Scheduling/Status 

7. 4. 6. 2. 6 

• P/L  Modes 

• Onboard  Core  Operations 

• Ground  Resources 

COPCC/POPCC  Facility  Management 

7. 4. 6. 2. 5 

Ground  Services 

• Interface  to  Mission  Scheduling 
Communication  Scheduling  Status 

7. 4. 3. 2. 2 

Center 

• Interface  to  Mission  Scheduling  and 
Network  Control  Center  (NCC) 

• Status  Interface  to  each  Ground 
Facility 

Common  Resource  Scheduling/Status 

7. 4. 3. 2. 3 

EOC's 

• Data  Handling  Centr  (DHC) 

• Level  Zero  Processing  Facilities  (LZPF) 

Facility  Management 

7. 4. 7. 2. 4 

POCC ' s , 

• Interface  to  Mission  Scheduling/Status 

• Interface  to  GSC  for  Comm.  Status 

Payload  (Independent)  Operations 

None  (SSI: 

Customers 

Scheduling/Status 

function) 

Facility  Management 

7. 4. 4. 2. 8 

• Interface  to  Mission  Scheduling/Status 

• Interface  to  GSC  for  Comm.  Status 

7-26 


Table  7. 3. 4-1 

Mission  Coordination  Functions  Map 
to  Ground  Elements  (cont'd) 


ELEMENT 


FUNCTIONS 


DHC, 

LZPF's 


NCC 


STS  MCC 


Facility  Management 

• Interface  to  GSC  Common  Resource 
Scheduling/Status 

TORSS/NASCOM  Scheduling/Status 

t Interface  to  GSC  Communication 
Scheduling/Status 

STS  Mission  Scheduling/Status 

• Interface  to  Mission  Scheduling 


REFERENCE 

SECTION 

7. 4.2. 3. 5 

7. 4. 5. 2. 5 


None  (SSIS 
function) 


None  (SSIS 
function) 


OMV/OTV  Remote  OMV/OTV  Remote  Operations  Scheduling/ 

Operations  Status 

Control  Center 

• Interface  to  Mission  Scheduling  for 
Proximity  Operations 

Free  Flyer  Free  Flyer  Scheduling/Status 

Control  Center(s) 

• Interface  to  SS  Mission  Scheduling 
for  Proximity  Operations 


None  (SSIS 
function) 


None  (SSIS 
function) 


where  layers  are  present  only  as  applicable  to  joint  operations.  For 
operations  within  the  proximity  of  the  Space  Station,  the  SSOCC  is  the 
controlling  ground  element  with  the  exception  that  its  schedule  is  generally 
dependent  upon  the  STS  schedule  for  operations  involving  the  shuttle. 

The  mission  schedule,  as  output  from  the  Space  Station  and  Platform  OCC's, 
drives  the  scheduling  of  the  ground  resources.  These  resources  include  1) 
the  ground  facilities  dedicated  to  mission  support,  i.e.  the  Control  Centers, 
POCC's,  and  EDC's;  and  2)  the  shared  communications  and  data  handling 
resources  managed  by  the  Ground  Services  Center.  The  facility  managers 
within  the  dedicated  facilities  and  the  GSC  in  turn  schedule  and  status 
their  resources,  reporting  to  Mission  Scheduling  only  the  status  and  change 
requests  that  impact  mission  operations. 
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Figure  7. 3. 4-1.  Mission  Coordination  Data  Flow 


The  mission  operations  schedule  and  status  data  tends  to  be  low  volume  and 
aperiodic  (event  driven)  in  nature.  The  exceptions  are  the  periodic 
reporting  of  core  status  among  the  Control  Centers  and  the  periodic 
broadcasting  of  timelined  information  of  general  interest,  e.g.  ephemeris. 

7. 3. 4. 2 Communications 

The  mission  schedules,  as  derived  by  the  Space  Station  and  Platform  Mission 
Scheduling  Systems,  are  input  to  the  Ground  Services  Center.  The  GSC 
develops  a communications  schedule  and  schedules  the  common  data  handling 
facilities  as  required  to  support  mission  operations. 

The  GSC  coordinates  with  the  Network  Control  Center  (NCC),  on  behalf  of  all 
SSP  elements,  the  scheduling  of  the  TDRSS  and  NASCOM  communication 
resources.  It  also  schedules  and  configures  the  data  handling  facilities, 
the  DHC  and  level  zero  processing  facilities,  for  mission  support. 

The  GSC  receives  status  reports  from  the  NCC  and  from  the  DHC  and  LZPF 
facility  managers  and  coordinates  reconf igurations . The  GSC  provides  data 
flow  reports  to  the  mission-dedicated  facilities'  managers  and  a summary 
report  to  the  OCC's  Mission  Scheduling  System.  Problem  resolution  occurs  on 
the  facility  level,  and  only  those  problems  which  cannot  be  resolved  and 
which  impact  mission  operations  are  reported  to  Mission  Scheduling. 

The  scheduling  data  and  status  reports  to  Mission  Scheduling  tend  to  be  low 
volume  and  aperiodic  (event-driven)  in  nature.  The  data  flow  reports  to  the 
individual  facilities  are  short  status  messages  that  are  issued  periodically 
(approximately  every  five  seconds). 

7.4  Strawman  Architecture 

7.4.1  Overview 

This  section  provides  an  overview  of  the  SSDS  ground  system.  Subsequent 
sections  will  provide  detail  concerning  interface  definition,  functional 
descriptions  and  design  approach  for  each  of  the  ground  elements. 
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Figure  7.4. 1-1  provides  an  overview  of  the  ground  system.  Correspondingly , 
Figure  7.4, 1-2  defines  the  space/ground  data  as  a function  of  TDRSS  single 
access  K and  S-Band  channels  between  the  ground  and  Space  Station/Platform 
elements.  Figure  7.4. 1-3  defines  the  ground  system  traffic  relative  to  the 
type  of  traffic  which  will  flow  between  the  ground  system  elements. 

The  approach  to  data  distribution  from  the  point  of  ground  system  receipt  at 
the  White  Sands/NASA  Ground  Terminals  and  handling  of  the  level  0 processing 
functions  features  a "hybrid  system"  — a hybrid  of  both  centralized  and 
distributed  processing.  The  Network  Topology  Trade  Study  that  supports  this 
approach  is  provided  in  the  Task  III  report.  Volume  I,  Section  III. 

To  review,  the  primary  dependencies  on  the  space  element  in  implementing  the 
hybrid  approach  are  as  follows: 

• all  data  is  packetized  and  framed  in  an  identical  CCSDS  format 

• all  low  rate  payload  data  (less  than  10  Mbps)  is  transmitted  in 
either  a real  time  or  playback  virtual  channel 

• each  high  rate  payload  uses  two  virtual  channels,  one  for  real  time, 
one  for  playback 

• core  data  is  assigned  two  virtual  channels  (real  time  and  playback) 

• payload  engineering  data  is  sent  as  a composite  of  all  payloads 
multiplexed  on  two  virtual  channels  (real  time  and  playback) 

With  this  data  definition  onboard,  the  Data  Handling  Facility  at  White  Sands 
splits  and  routes  the  virtual  channels  to  the  ground  elements  as  follows: 

• low  rate  payload  data  and  payload  engineering  data  to  GSFC  for  real 
time  distribution  to  POCCs  (required  for  real  time  operations),  and 
level  0 processing  for  data  set  distribution  to  designated  RDC's. 

• High  rate  payload  data  to  high  rate  Level  0 Processing  Facilities 
(LZPF)  at  GSFC,  JPL,  and  LARC  for  as  needed  real  time  distribution  to 
related  POCCs,  and  level  0 processing  for  data  set  distribution  to 
designated  RDCs  which  are  assumed  to  be  co- located  with  the  high  rate 
LZPFs.  Note  that  this  identification  is  based  on  the  1997  Langley 
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Figure  7 .4.1-1.  Ground  SSDS  Topology 
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database  and  could  change  as  high  rate  missions  are  added  or  deleted 
from  the  program 

• core  data  to  the  appropriate  Control  Center  for  real-time  monitoring 
and  control,  and  archive  in  the  Engineering  Data  Center. 

Customers  interface  into  the  ground  system  for  payload  control  through  an 
existing  POCC  (either  at  the  POCC  or  via  remote  terminals  connected  via  a 
Customer  Inteface  Element)  or  as  independent  customers  with  direct  command 
interface  through  the  DHC.  Customers  receive  their  level  0 processed  data 
through  an  LZPF  or  through  designated  RDCs  (not  an  SSDS  element) . It  should  be 
noted  that  independent  customers,  especially  for  high  rate  payloads,  could 
provide  their  own  level  0 processing  function. 

7.4.2.  Data  Handling  Center  (DHC) 

In  the  strawman  design,  the  Data  Handling  Center  (DHC)  serves  as  the 

space/ground  gateway  - receiving,  buffering,  and  routing  data  to  the  ground 

data  distribution  network  from  the  T'DRSS  ground  system  and  vice  versa.  The 
DHC  is  located  at  White  Sands  and  directly  interfaces  to  the  existing  and 
future  NASA  Ground  Terminals,  and  to  the  Data  Distribution  Network  (e.g., 
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WASCOM) . The  strawman  design  emphasizes  a relatively  simple  DHC  which 
directly  pipes  most  data  to  LZPF's  the  SSOCC,  or  platform  OCC's  at  major  IM ASA 
centers  for  further  processing.  Uplink  frame  build  and  uplink  authorization, 
however  are  performed  at  the  DHC  due  to  its  centrality  as  the  ground/space 
gateway . 

7.4.2. 1 Functional  Interface  Description 

The  functional  interfaces  for  the  DHC,  illustrated  in  figure  7.4. 1-1  are 
discussed  in  the  sections  below. 
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7. 4. 2. 1.1  NASA  Ground  Terminal(s) 


The  Data  Handling  Center  will  be  receiving  and  transmitting  data  to  the  NGT's, 
each  of  which  will  be  receiving  data  from  the  Space  Station  Elements  (SS,  COP, 
and  POP).  Data  and  commands  are  in  the  CCSDS  packet  format,  with  internal 
core  and  payload  data  fully  independent  of  transfer  frame  structure.  In  the 
strawman  design  it  is  assumed  that  none  of  the  physical  TDRSS  elements 
themselves  are  dedicated  to  Space  Station,  including  the  NGT's.  That  is, 

Space  Station  data  may  be  received  through  either  of  the  NGT  interfaces,  and 
the  physical  interfaces  are  identical. 

7.4.2. 1.2  Ground  Services  Center 

The  DHC  interfaces  with  the  Ground  Services  Center  for  purposes  of  resource 
coordination.  All  communication  with  the  NCC  is  through  the  GSC  to  assure 
coordination  of  SSDS  requests.  The  DHC  manages  itself  using  the  inputs 
provided  by  the  GSC. 


Specifically,  the  GSC  provides  the  following  to  the  DHC: 

• TDRSS/Data  Distribution  Network  Schedule  Information  — for  scheduling  of 
the  NGT — DHC  and  the  DHC — Data  Distribution  Network  interfaces.  The 
strawman  design  attempts  to  minimize  the  need  for  scheduling  through  the 
use  of  dynamic  bandwidth  allocation  techniques,  but  automated  scheduling 
of  high  bandwidth  resources  seems  inevitable. 

• Mission  Schedules  — also  to  allow  support  for  high  rate  missions. 

• Routing  Tables  — tables  which  map  CCSDS  application  ID's  to  their 
uplink/downlink  destinations  and  thus  allow  data  to  be  correctly  routed 

• Authorization  Tables  — tables  which  map  CCSDS  application  ID's  with 
sources  allowed  to  be  sending  uplink  data  and  commands  to  that  destination. 
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The  DHC  provides  the  following  information  to  the  GSC: 


• Equipment  Status  — including  configuration  data  and  fault  reporting  which 

effects  other  SSDS  elements  r 

• Data  Quality  — as  determined  by  the  Reed  Solomon  decoding  of  CCSDS 
transfer  frames 

• Data  Accounting  Information  — on  a CCSDS  transfer  frame  basis 


7.4.2. 1.3  Level  Zero  Processing  Facilities  (LZPF's) 

Payload  scientific  and  engineering  data  are  sent  directly  to  the  LZPF's.  The 
DHC  acts  as  a bent  pipe  for  this  data,  supporting  basic  services  to  remove 
space-ground  link  communications  artifacts,  to  provide  line  outage  protection, 
and  to  provide  rate  smoothing.  The  DHC  does  not  provide  store-and-forward 
service,  batching,  or  merging  of  recorder  data.  These  services  are  provided 
at  LZPF's  located  at  major  NASA  centers.  High  rate  data  is  sent  directly  to 
the  LZPF's  associated  with  GSFC,  JPL,  and  LARC.  Low-rate  data  is  sent  directly 
to  the  LZPF  at  GSFC.  The  downlink  CCSDS  packets  are  error  corrected  and 
formatted  by  the  DHC  for  transport  over  the  ground  data  distribution  network. 
The  DHC  does  not  require  knowledge  of  the  internal  data  formats  since  it 
routes  to  the  LZPF's  according  to  virtual  channel. 

7.4.2. 1.4  Operations  Control  Centers  (OCC's) 

The  SSOCC,  COPCC  and  POPCC  send  uplink  data  to  the  DHC  and  receive  downlink 
data  directly  from  the  DHC.  Data  traffic  includes  engineering  data,  commands, 
audio,  and  video.  Payload  OCC's  interface  directly  with  the  DHC  for  command 
uplink  as  well  as  audio  and  video  links,  but  receive  downlink  engineering  and 
quicklook  data  through  their  corresponding  LZPF's.  The  DHC  will  accept  uplink 
traffic  only  if  an  appropriate  authorization  has  been  issued  by  the  GSC  and 
the  source  of  the  traffic  has  been  identified  through  a secure  session  logon. 
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7.4.2. 1.5  Independent  Customers 


The  Independent  Customers  send  uplink  data  to  the  DHC  through  links  similar  to 
those  provided  to  the  payload  OCC's.  As  with  the  payload  OCCs  all  downlink 
data  is  provided  to  the  independent  customers  through  the  GSFC  LZPF  (which  is 
responsible  for  the  delivery  of  all  low  rate  payload  data). 

7. 4. 2. 2 Functional  Description 

The  Data  Handling  Center  is  the  direct  interface  between  the  space-ground 
communication  link  (TDRSS)  and  the  ground  data  distribution  network.  Its 
functions  are  essentially  limited  to  those  of  a gateway.  In  the  strawman 
design,  it  will  perform  the  following  functions: 


DOWNLINK  DATA  PROCESSING 

Bulk  Data  Recording  — to  provide  line  outage  protection 

CCSDS  Frame  Synchronization  — to  support  routing  of  CCSDS  virtual  channels  to 
LZPF's,  SSOCC,  and  platform  CC's  on  a transfer  frame  basis 

Reed-Solomon  Error  Correction  — to  remove  ground-space  link  noise 

Data  Accounting  — on  a CCSDS  transfer  frame  basis 

Virtual  Channel  Routing  — to  pipe  virtual  channels  to  appropriate  LZPF's, 
SSOCC,  and  platform  OCC's 

Link  Performance  Monitoring  — to  provide  link  quality  data  to  the  GSC 

Retransmission  Services  — to  support  retransmission  in  the  event  of 
communications  link  or  external  element  failure 

Data  Distribution  Network  Interface  — to  support  distribution  of  virtual 
channels 
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UPLINK  DATA  COLLECTION 


Data  Distribution  Network  Interface  — to  support  direct  command  and  data 
uplink  interfaces  with  all  authorized  SS  ground  elements 

Uplink  Authorization  — to  provide  security  and  coordination  of  uplink  access 
according  to  schedules  and  authorization  tables  provided  by  the  GSC 

Frame  Synchronization/Build  — to  format  and  multiplex  commands  'and  data  on 
the  appropriate  CCSDS  uplink  virtual  channels 

Reed-Solomon  Error  Encoding  — to  provide  for  uplink  noise  protection 

Link  Performance  Monitoring  — to  provide  link  quality  data  to  the  GSC  and 
issues  of  uplink  requests 


DHC  FACILITY  MANAGEMENT 


Configuration  Management  — to  manage  equipment  and  gateway  configuration 

External  Coordination  — to  accept  schedules  from  and  coordinate  with  other 
SSDS  elements  through  the  GSC 

Cold  Start,  Restart  and  Switchover  — to  manage  startup,  restarts,  and 
switchovers 

DHC  buffering  of  data  is  limited  to  functions  required  to  accomplish  line 
outage  protection  and  data  rate  smoothing.  Downlink  payload  data  is  separated 
on  the  basis  of  virtual  channels,  corrected,  accounted  for  on  a transfer  frame 
basis,  and  routed  to  appropriate  LZPF's  for  further  Level  Zero  processing.  The 
DHC  is  responsible  for  checking  authorization  for  command  uplink  and  merging 
data  into  appropriate  virtual  channels.  However,  the  DHC  has  no  command 
scheduling  responsibilities,  proceeding  only  on  the  basis  of  authorization 
tables  issued  by  the  GSC. 
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We  have  not  included  functions  for  routing  audio  and  video  data  since  these 
functions  are  not  within  the  scope  of  the  SSOS,  but  our  implicit  assumption  is 
that  this  data  is  routed  to  the  OCCs/POCCs  and  received  from  the  OCCs/POCCs  on 
dedicated  CCSDS  virtual  channels. 

7. 4. 2. 3 Design 

This  section  discusses  a high  level  design  approach  to  the  DHC.  The  following 
key  assumptions  were  made: 

• Standards  from  the  Consultative  Committee  for  Space  Station  Data  Systems 
are  used  for  the  TDRSS  space-ground  link,  modified  as  described  in  Section 
4 (end— to— end  data  flow) . The  proposed  modifications  support  space/ground 
transparency  in  formatting  and  addressing  and  bi-directional  telemetry  and 
commands.  The  standards  include  the  use  of  Reed-Solomon  coding  to  guard 
against  errors.  Convolutional  coding,  however,  is  not  used  since  it 
duplicates  some  of  the  functionality  of  Reed-Solomon  coding  at  a high 
bandwidth  cost.  Customers  requiring  high  levels  of  immunity  to  Gaussian 
noise  are,  of  course,  free  to  implement  their  own  interior  coding  schemes 
independently  of  standard  SSDS  services. 

• The  CCSDS  virtual  channel  construct,  and  not  CCSDS  segmentation,  is  used 
for  all  experiments.  Individual  virtual  channels  will  be  devoted  to  high 
rate  experiments  while  low  rate  experiments  will  be  multiplexed  on  a 
single  virtual  channel  using  the  CCSDS  packet  telemetry  standard. 

• Standards  compatible  with  the  International  Standards  Organization  (ISO) 
seven  layer  model  for  Open  Systems  Interconnect  (OSI)  are  used  for  the 
ground  data  distribution  network. 

• The  ground  data  distribution  network  provides  OSI  compatible  services  for 
dcta  delivery  from  the  DHC  to  the  LZPFs  and  OCCs.  In  particular,  the 
network  header  structure  is  independent  of  data  format  and  data  is 
delivered  with  all  network  artifacts  removed. 
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• Payload  scientific  and  engineering  data  is  received  on  links  organized  so 
that  individual  CCSDS  virtual  channels  may  be  routed  directly  to  LZPFs  and 
OCCs . 

• Command  and  core  engineering  data  are  routed  through  separate  CCSDS  links 
through  the  TDRSS  S-band  forward  and  return  link  services. 

• Data  is  delivered  to  the  DHC  by  the  NGT  at  constant  rates  with  fill 
inserted  as  appropriate  to  maintain  data  rates. 

• All  audio  and  video  will  be  sent  on  separate  virtual  channels.  No 
conversion  or  reformatting  is  required  at  the  DHC. 

A detailed  function  diagram  for  the  Data  Handling  Center  is  shown  on  Figure 
7. 4. 2. 3-1.  Briefly,  the  downlink  data  is  captured  on  high  density  data 
recorders  (for  line  outage  protection),  frame  synchronization  is  performed, 
Reed-Solomon  error  correction  is  done  on  the  transfer  frames,  and  the  CCSDS 
virtual  channels  are  split  and  routed  to  the  LZPFs  at  GSFC,  JPL,  and  LARC  and 
to  CCs  (SSOCC,  COPOCC,  and  POPOCC) . For  high  rate  data,  a rate  smoothing 
function  can  be  implemented  through  a pool  of  magnetic  disks  or  rewriteable 
optical  disks.  The  tradeoff  between  storage  costs  (an  SSDS  element)  and 
communication  costs  (outside  the  SSDS)  for  rate  smoothing  was  addressed  in  the 
Network  Topology  Tradeoff  Study.  Expected  improvements  in  communication 
technology  may  make  the  rate  smoothing  function  unnecessary.  No  further 
processing  is  done  on  the  downlink  data  at  the  DHC.  Payload  OCC's  and 
independent  customers  receive  their  data  through  the  LZPFs,  primarily  GSFC, 
which  is  the  LZPF  to  which  all  low  rate  data  is  routed. 

The  uplink  process  involves  an  authorization  step  similar  to  those  found  in 
secure  network  gateways.  The  DHC  routinely  receives  authorization  tables  from 
the  GSC.  These  tables  define  uplink  access  schedules  and  privileges  for  SS 
users.  Since  command  scheduling  and  mode  change  authorization  are  accomplished 
onboard  the  spacecraft,  these  tables  define  only  a first  line  of  protection 
against  unauthorized  spacecraft  data  system  access  and  the  user  is  presented 
with  transparent  access  to  the  onboard  system  once  a session  is  established. 
The  DHC  serves  simply  as  a secure  gateway  to  the  onboard  LAN  rather  than  a 
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Figure  7.4.2.3-1 . White  Sands  DHC 


command  verification  station.  The  DHC  will  accept  commands  and  uplink  data 
packets  from  the  data  distribution  network,  multiplex  them  in  dedicated 
virtual  channels,  performing  framing,  error  encoding,  and  transmitting. them  to 
the  NGTs . 


The  following  subsections  discuss  each  of  the  major  functions  within  the  DHC 
and  our  design  approach  to  these  functions. 


7. 4. 2. 3.1  Preprocessing 

Preprocessing  for  the  DHC  is  achieved  primarily  through  the  use  of  custom 
hardware  (e.g.  high  speed  CMOS  or  gallium  arsenide  IC's)  to  provide  front  end 
functions  such  as  transfer  frame  synchronization,  Reed  Solomon 
decod ing/encoding,  and  splitting  of  virtual  channels.  Use  of  the  CCSDS 
transfer  frame  format  for  the  ground-space  communications  link  will  greatly 
simplify  design  of  this  hardware  assuming  that  a single  fixed  length  is  used 
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for  all  transfer  frames  in  a physical  link  and  that  all  transfer  frames  are 
Reed— Solomon  encoded.  This  efficiency  is  achieved  through  the  relative 
simplicity  of  synchronizing  to  and  decoding  a fixed  length  format. 

The  use  of  monolithic  IC's  implementing  these  functions  is  motivated  by  the 
high  bandwidths  and  associated  timing  problems.  Tools  for  implementing  this 
hardware  (and  presumably  a number  of  off-the-shelf  chips)  will  likely  be 
available  as  by-products  of  the  DoD  VHSIC  program. 

7. 4. 2. 3. 2 Routing  & Transmission 

The  CCSDS  standard  does  not  explicitly  define  the  method  for  multiplexing 
transfer  frames.  To  simplify  scheduling  and  minimize  reconf iguration  burdens 
the  design  allows  for  fully  dynamic  allocation  of  bandwidth  to  individual 
virtual  channels.  Transfer  frames  may  be  multiplexed  in  any  manner 
appropriate  to  the  bandwidth  requirements  of  a particular  virtual  channel.  As 
individual  transfer  frames  are  received  they  are  routed  through  the  high  rate 
network  links  to  the  LZPF's,  and  OCC's.  Routing  is  done  according  to  routing 
tables  received  from  the  GSC.  The  DHC's  function  is  simply  to  translate  the 
virtual  channel  number  of  the  transfer  frame  to  a network  address  and  pass  the 
frame  and  associated  destination  to  the  services  associated  with  the  high  rate 
network.  It  is  assumed  that  the  ground  network  simply  delivers  the  frame  to 
the  address  with  no  communications  artifacts  added. 

The  design  allows  for  a possible  rate  smoothing  function.  Certain  payloads 
with  high  peak  and  relatively  low  average  bandwidth  requirements  and  no  need 
for  real-time  data  access  may  make  use  of  this  function  to  reduce 
communications  cost. 

7. 4. 2. 3. 3 Uplink  Access  Authorization 

Since  the  design  provides  a sophisticated  command  management  system  onboard 
the  space  station  elements,  minimal  command  management  is  required  on  the 
ground.  The  DHC  is  required  to  determine  whether  a source  sending  uplink  data 
is  allowed  to  be  sending  data  to  the  particular  destination  denoted  by  the 
application  process  ID  in  the  CCSDS  packet  header.  This  must  be  done  for  all 
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data,  since  it  will  not  be  possible  to  determine,  with  certainty,  whether  a 
particular  set  of  bits  is  uplink  data  or  uplink  commands. 

This  function  would  be  performed  by  comparing  the  origin  and  destination 
address  in  the  network  packets,  with  the  application  process  ID  in  the  CCSDS 
header.  The  processing  would  thus  require  the  network  interface  to  buffer  and 
transmit  the  source  ID  to  the  DHC  authorization  processor. 

7. 4. 2. 3. 5 DHC  Facility  Management 

DHC  facilities  are  managed  by  a fault-tolerant  processor.  Its  primary 
functions  are  to: 

• Receive  schedules,  routing  tables,  retransmission  requests,  and 
authorization  tables  from  the  GSC. 

• Load  routing  tables  in  the  virtual  channel  routing  hardware. 

• Load  authorization  tables  in  the  uplink  authorization  processor. 

• Reconfigure  the  line  outage  recorders  and  preprocessing  hardware  to 
implement  retransmission. 

• Provide  equipment  redundancy  management. 

7.4.3  Ground  Services  Center  (GSC) 

The  Ground  Services  Center  (GSC)  provides  communication  and  common  resource 
coordination  for  the  ground  system.  It  serves  to  coordinate  the  scheduling  of 
the  communication  and  ground  facility  resources  shared  among  the  Space 
Station,  COP,  and  POP  programs.  These  shared  facilities  include  the  Data 
Handling  Center,  and  the  Level  0 Processing  Facilities. 


The  GSC  also  collects  status  and  accounting  information  from  these  facilities 
(outages,  etc)  and  prepares  reports  of  this  information  to  both  customers  and 
the  Global  System  Manager  at  the  Control  Centers.  The  GSC  performs  SSIS 


7-42 


functions  involving  the  collection  of  billing  and  usage  information  for  ground 
element  resources  used  by  customers  and  the  processing  of  customer  bills. 

7.4.3. 1 Functional  Interface  Description 

By  the  nature  of  its  functions,  the  GSC  requires  interfaces  to  the  various 
Space  Station  Program  Elements  and  also  to  elements  such  as  the  I\1CC  which  are 
in  the  SSIS,  as  shown  on  Table  7.4.3. 1-1.  The  traffic  along  these  interfaces 
generally  consists  of  low  volume  configuration,  status,  and  administrative 
data,  and  voice  communications.  An  exception  to  this  may  be  the  usage  and 
accounting  information,  which  could  become  voluminous. 

The  periodic  status  information  is  transmitted  between  the  elements  on  a 
regular  and  frequent  (seconds)  basis  in  the  form  of  standard  status  messages. 
Scheduling  information  will  be  transmitted  between  the  elements  on  an 
aperiodic  and  less  frequent  (minutes  and  hours)  basis  as  required  in  the  form 
of  schedule  requests,  responses,  and  reports.  Usage  and  accounting  information 
will  be  collected  on  a scheduled,  polled  basis  from  each  element.  That  is, 
each  element  will  be  responsible  for  recording  this  information,  and  the  GSC 
will  poll  each  element  on  a routine  schedule(e .g . , hours  or  days)  and  a file 
transfer  initiated. 

Application  level  protocols  for  this  information  are  necessary  to  facilitate 
operation  of  the  distributed  ground  system  elements.  This  is  especially  true 
since  the  control  of  the  SSDS  is  split  for  programmatic  reasons  between  that 
under  the  domain  of  the  GSC  (common  resources)  and  that  controlled  by  the 
Control  Centers  (development  of  mission  schedules),  leading  to  significant 
coordination  issues.  Coordination,  rescheduling  and  status  reporting  to 
customers  would  be  very  difficult  in  this  distributed  environment  without 
these  appliation  level  interface  agreements. 

7. 4. 3. 2 Functions 

The  GSC  performs  the  following  functions: 

• Coordination  Of  Shared  Resouces 
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Table  7. 4. 3. 1-1 

GSC  Functional  Interfaces  To  SSDS  Ground  Elements 


Element 

Interface  Traffic 

Purpose 

DHC 

Scheduling  Messages 

Resource  & Schedule  Coordination 

Status  Messages 

Perf.  Monitoring,  Redundancy, 
Configuration  Mgmt 

Resource  & Data 
Quality  Records 

Customer  Billing  & 
Fault  Isolation 

Routing  Tables, 
Authorization  Tables 

DHC  Configuration 

LZPFs 

Scheduling  Messages 

Resource  & Schedule  Coordination 

Status  Messages 

Perf.  Monitoring,  Redundancy, 
Configuration  Mgmt 

Resource  & Data 
Quality  Records 

Customer  Billing  & 
Fault  Isolation 

SSOCC 

Scheduling  Reports 
Status  Reports 

Resource  & Schedule  Coordination 
Status  Reporting 

POPCC 

Scheduling  Reports 
Status  Reports 

Resource  & Schedule  Coordination 
Status  Reporting 

COPCC 

Scheduling  Reports 
Status  Reports 

Resource  & Schedule  Coordination 
Status  Reporting 

POCCs 

Scheduling  Reports 
Status  Reports 

Resource  & Schedule  Coordination 
Status  Reporting 

EDC 

Scheduling  Reports 
Status  Reports 

Resource  & Schedule  Coordination 
Status  Reporting 

NCC 

(SSIS  Element) 

Scheduling  Messages 
Reports 

Resource  & Schedule 
Coordination 

Status  Messages 

Status  Monitoring 

Resource  & Data  Quality 
Records 

Customer  Billing  & 
Fault  Isolation 

Customer  Interface 
Element(s)  (CIEs) 

Network  Status/Schedule 
Data  Accounting  & 
Quality  Reports. 

Usage  Reports  & Bills 

Customer  Support  for 
Mission  Coordination,  etc. 

Element  and 
Center  Gateways 

Authorization  and 
Configuration  Tables 

Network  Management 
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- Scheduling 

- Configuration  Management 

- Redundancy  Management 

• Performance  & Status  Monitoring 

• Usage  Tracking,  Data  Accounting  (system  wide)  and  Fault  Isolation  (to 
common  resource  elements) 

Shared  resources  are: 

• Communications  Resources 

• Data  Handling  Center  Resources 

• Level  0 Processing  Facility  Resources 


It  is  envisioned  that  the  driver  for  scheduling  and  re— configuration  will  be 
the  TDRSS  resources . The  other  common  resources  will  likely  be  far  more  stable 
as  they  are  designed  and  sized  to  require  a minimum  of  re-conf iguration  in 
this  design. 

7. 4. 3. 2.1  Control  Center  Facility  Manager  Interface 

The  scheduling  of  the  LZPF  and  DHC  common  resources  will  be  determined  by  the 
schedules  received  from  the  Control  Center  scheduling  systems.  Customers 
(independently  or  at  POCCs)  will  first  develop  their  mission  schedules  by 
communicating  to  the  OCC  scheduling  systems  via  the  Customer  Interface 
Elements  and  the  Development  and  Control  Network. 

The  Control  Centers  will  communicate  these  combined  mission  schedules  in  the 
form  of  reports  to  the  GSC.  The  GSC  and  the  Control  Centers  will  then 
negotiate  via  scheduling  messages. 

The  GSC  thus  receives  the  schedule  reports  for  the  SS,  POP,  and  COP  from  the 
scheduling  functions  at  each  Control  Center . It  then  configures  the  common 
resources  of  the  ground  system  to  support  the  SSP  schedule. 
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The  GSC  receives  status  reports  on  communications  resources  from  the  NCC, 
summarizes  them  along  with  the  status  of  other  common  resources  in  a manner 
appropriate  for  use  by  the  Control  Centers  and  provides  these  reports  to  the 
Control  Centers  facility  managers. 

7. 4. 3. 2. 2 Communications  Resources 

The  GSC  receives  schedule  requests  from  the  Control  Centers  for  the  use  of 
communications  resources.  These  include  both  the  TDRSS  resources  and  the 
ground-to-ground  communications  resources.  It  is  assumed  that  the  SSP  will  be 
guaranteed  a certain  level  of  TDRS  service.  Changes  to  the  schedule  may 
result,  for  example,  in  changes  to  the  TDRS  schedule,  re-configurations  of  the 
Transport  Network  DOMSAT  and  other  links,  and  updating  routing  tables. 

GSC  thus  provides  an  interface  between  the  elements  of  the  Space  Station 
Program  and  the  Network  Control  Center.  It  accepts  the  schedule  requests  from 
the  Control  Centers,  integrates  them,  coordinates  schedules  and  resolves 
conflicts  with  those  other  common  resources,  and  coordinates  on  behalf  of  all 
SSP  elements  with  the  NCC  to  develop  the  schedule  for  the  support  of  the  SSP. 
It  also  interfaces  with  the  SSP  elements  to  communicate  NCC  initiated  schedule 
changes.  Finally,  the  GSC  receives  reports  of  communications  resource  use  and 
data  accounting. 

7. 4. 3. 2. 3 DHC  & LZPF  Resources 

The  GSC  receives  schedule  requests  from  the  Control  Centers  for  use  of  the  DHC 
and  LZPF  resources.  The  GSC  interfaces  with  the  DHC  and  LZPF  facility 
managers  to  assure  that  the  DHC  and  LZPF  configurations  are  consistent  with 
other  shared  resources  (e.g.,  that  virtual  channels  are  routed  to/from 
available  communication  links)  and  support  the  Control  Center  SS  schedule,  and 
vice  versa.  It  thus  accepts  the  schedule  requests  from  the  Control  Centers, 
integrates  them,  coordinates  schedules  and  resolves  conflicts  in  scheduling 
the  communications  resouces. 

These  services  implemented  by  the  DHC  resources  are  described  in  Section  7.4.2 
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Scheduling  messages  may  be  needed  to  assure  that  the  configuration  of  the  DHC 
is  coordinated  with  other  elements: 

o TDRSS/NASCOM  interfaces 

o routing  tables 

o authorization  data 

The  services  implemented  by  the  LZPF  are  described  in  Section  7.4.5.  The 
configuration  of  the  Level  0 resources  must  be  consistent  with  other  ground 
elements  to  assure  support  of  all  payloads.  Tables  showing  the  correspondence 
between  the  packet  telemetry  application  ID  and  the  customer  or  other 
destination  must  be  maintained. 


The  GSC  receives  status  messages  from  the  DHC  and  the  LZPF  and  coordinates 
re-conf igurations  as  appropriate  to  respond  to  changes  in  status.  An  example 
of  this  might  be  re-routing  or  buffering  of  data  in  the  event  of  an  LZPF  or 
communications  failure,  or  messages  to  the  Control  Centers  to  reschedule 
missions  if  a by-pass  configuration  cannot  be  implemented. 

The  GSC  also  collects  resource  usage  information  from  the  DHC  and  LZPF  for 
both  SSDS  and  SSIS  functions.  An  SSIS  use  of  this  data  is  for  the  preparation 
of  bills  for  the  use  of  chargeable  resources. 

7. 4. 3. 3 Design  Approach 

The  GSC  requires  the  following  components  as  shown  on  Figure  7. 4. 3. 3-1: 

o Gateways 

DHC,  LZPF 
NCC 

- Control  Centers 

- DSIT  Environment  (Not  shown) 

The  gateways  accept  the  status,  scheduling,  and  usage  messages  and  reports 
and  route  them  to/from  the  GSC  local  data  distribution  network  (e.g.,  a LAN), 
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Figure  7. 4. 3.3-1.  Ground  Service  Center 


performing  protocol  conversion  as  necessary.  The  gateways  will  thus  consist  of 
modems,  protocol  converters,  etc.  The  status  and  scheduling  messages  will  be 
transmitted  over  dedicated  lines,  with  dial-up  back  up,  with  the  usage 
information  collected  on  a polled  basis. 

• Local  Data  Distribution  Network 

The  local  area  distribution  network  provides  communication  between  the 
elements  of  the  GSC.  At  least  two  processing  capabilites  are  required: 

• General  Purpose  Processor  (for  such  functions  as  billing) 

• Scheduling  Processor  (AI  based) 

The  general  purpose  processor(s)  must  support: 

- Monitoring  of  status  data  (e.g,  threshold  or  outage  alerts) 

- report  generators  (database  reports) 

- Data  Accounting  Reports  (system  wide) 

- Billing  & Resource  Tracking 

- Trending/Utilization  Analysis 

It  is  noted  that  the  processing  required  to  support  billing  and  usage 
tracking  is  an  SSIS  function.  However,  such  usage  information  can  be  used  for 
other  functions  than  billing.  For  example,  it  could  be  sorted  by  processing 
element  as  opposed  to  user/customer,  and  a trend  analysis  performed  to 
determine  outage  patterns  and  to  generate  availability  reports.  Data  quality 
information  could  be  analyzed  to  isolate  problems  to  particular  ground 
elements . 

At  least  two  databases  and  associated  storage  devices  are  required: 

• Database  Processor  (Accounting  & Status) 

• Operational  Database  (Scheduling) 

A modern  database  capability,  such  as  relational,  would  likely  be  used  to 
isolate  changes  in  the  database  format  from  impacting  the 
GSC  applications  software. 
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Finally , workstations  are  needed  for  operators  support.  It  does  not  appear 
these  workstations  would  need  to  be  highly  intelligent  workstatations  but  need 
only  support  access  to  the  processors  and  databases. 

7.4.4  Payload  Operations  Control  Centers  (POCC's) 

The  Payload  Operations  Control  Centers  (POCC's)  support  all  phases  of 
operations  for  a single  payload  or  complement  of  payloads.  These  phases 
include  prelaunch  integration  and  test  of  payloads,  either  at  the  launch  site 
or  at  an  off-site  facility.  The  POCC  must  also  support  ground  and  flight  crew 
training  during  the  prelaunch  phase.  POCC  Control  and  monitoring  functions 
that  are  unique  to  the  payload  applications,  training  and  simulations  are 
outside  the  boundaries  of  the  SSDS.  However,  the  POCC  functions  that  provide 
standard  services  — the  interface  to  the  DHC  and  the  GSC,  and  that  support 
ground  system  management  are  within  the  SSDS. 

7.4.4. 1 Interface  Description 

Figure  7. 4. 4-1  shows  the  POCC's  interface  diagram  with  six  other  SSDS 
elements.  Brief  descriptions  of  each  interface  are  as  follows: 


Real-Time  P/L  Data 

Status  and 

Level  <p 

P/L  Eng  Data 

Control  Data 

SSOCC 

Proc  Fac 

POPOCC 

I 

COPOCC 

Voice 

1 

Schedule  Info 

DHC 

Video 

POPP 

Facility  Staus 

GSC 

^ Uplink  CMD 

i 

i i 

i 

Archive  Request 

Quick- Look  Data 

EDC 

^ and  Retrieval 

P/L  Command 

Customer 

Figure  7.4. 4-1.  Payload  Operations  Control  Center  Interface 
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7.4.4. 1.1  Level  0 Processing  Facility  (LZPF) 


Both  the  real  time  payload  science  data  and  payload  engineering  data  will  be 
conditioned  at  the  LZPF  before  routing  from  the  LZPF  to  Payload  Operations 
Control  Centers  (POCC's).  The  data  will  then  be  processed  and  displayed  for 
operators  in  standard  operator  selected  formats  upon  request.  In  addition, 
quicklook  displays  would  be  made  available  for  customer  use  at  this  location. 

7.4.4. 1.2  Data  Handling  Center  (DHC) 

Both  voice  and  video  data  are  communicated  between  the  DHC  and  POCC's  in  both 
uplink  and  downlink  directions.  However,  the  transmission  method  for  both 
voice  and  video  are  outside  the  scope  of  SSDS  study.  All  uplink  payload 
commands  are  issued  from  POCC's  to  the  the  space  elements  via  the  DHC.  The 
LOGON  command  authorization  will  be  done  at  the  DHC. 


7.4.4. 1.3  Engineering  Data  Center  (EDC) 

The  operators  and/or  customers  in  a POCC  may  desire  either  core  data  not 
previously  requested  in  the  ancillary  data  package,  or  historical  data  from 
the  Engineering  Data  Archives  and  could  request  the  desired  parameters  over  a 
low  data  rate  line  from  the  EDC. 

7.4.4. 1.4  Control  Centers  (SSOCC,  POPCC,  COPCC) 

The  interface  between  POCC's  and  the  appropriate  Control  Centers  provides  for 
schedule  coordination  to  establish  the  particular  POCC's  payload  operations 
needs  on  the  mission  schedule. 

7. 4. 4. 1.5  Ground  Service  Center  (GSC) 

POCC's  interface  with  the  GSC  for  Network  status,  schedule  and  data  accounting 
status,  and  data  quality  and  usage  reports. 
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7 . 4 . 4 . 1 . 6 Customers 


Customers  will  interface  with  the  POCC’s  either  remotely  or  at  the  location  of 
the  POCC  for  the  purpose  of  controlling  their  payloads.  These  functions  will 
include  quicklook  monitoring  of  payloads  and  command  control  of  payload 
operations . 

7. 4. 4. 2 Function  Description 

A functional  block  diagram  of  the  Payload  Operations  Control  Centers  (POCC)  is 
shown  in  Figure  7. 4. 4-2.  As  all  functions  are  not  within  the  SSDS,  a design 
approach  for  POCC's  is  not  included  in  this  report. 

7. 4. 4. 2.1  External  Interface  Management 

The  External  Interface  Subsystem  provides  the  interface  to  the  wide  area 
and/or  local  area  networks  connecting  each  POCC  to  the  other  SSPE's.  The 
subsystem  supports  communication  link  monitoring,  transmission  error 
detection,  and  protocols  requiring  acknowledgements  and  retransmissions . 


Figure  7.4.4-2.  Payload  Operations  Control  Center  Functional  Block  Diagram 
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7. 4. 4. 2. 2 Payload/Core  Quick  look  Monitoring 

Personnel  at  a POCC  must  have  the  capability  to  evaluate  the  performance  of  a 
specific  payload.  Payload  data  and  preselected  subsets  of  ancillary  data  will 
be  processed  for  quicklook  purpose.  The  quicklook  displays  are  made  available 
for  customers  use  at  the  POCC  location  or  remotely  for  customer  evaluation  of 
payload  performance. 

7. 4. 4. 2. 3 Communications  Processing 

This  subsystem  consists  of  the  audio  and  video  processing/distribution  systems 
within  the  POCC. 

7. 4. 4. 2. 4 Interface  Processing 

This  subsystem  manages  the  functional  interfaces  to  the  other  ground  elements 
- DHC,  LZPF,  other  Control  Centers,  EDH,  GSC  and  customers.  The  processing 
consists  of  interpreting  incoming  messages,  establishing  interface  connection, 
building  outgoing  response  or  service  request  messages,  and  maintaining 
interface  protocols. 

7. 4. 4. 2. 5 Data  Base  Management  System 

This  subsystem  provides  the  data  base  definition  for  interpretation  of  all 
payload  data  and  ancillary  data  received  by 

the  POCC,  and  for  the  bit  configuration  of  all  payload  commands  generated  by 
the  POCC. 

7. 4. 4. 2. 6 Payload  Systems  Operation 

This  function  includes  the  generation  of  uplink  real  time  payload  commands  and 
command  loads  from  operator' s/customer' s initiation  requests.  The  command 
management  functions  including  authorization  check,  restricted  and  constrained 
commands  check  and  scheduling  conflicts  check  will  be  done  at  the  DHC 
(authorization  check)  and  onboard. 
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7. 4. 4. 2. 7 Ancillary  Data  Archive 


Operators/customers  may  desire  either  core  data  not  previously  selected  in  the 

ancillary  data  package,  or  historical  data  from  the  Engineering  Data  Center. 

Via  this  subsystem,  the  POCC  requests  data  from  the  EDC,  and  archives  it  for 

processing  and  display. 

7. 4. 4. 2. 8 Facility  Configuration  Management  and  Scheduling 

This  subsystem  configures  the  POCC  processors  for  data  monitoring,  display  and 
payload  command  and  control  operations.  It  also  provides  the  scheduling 
functions  and  interface  with  appropriate  Control  Centers  for  scheduling 
payload  operations.  Its  interface  with  the  GSC  provides  for  network  and 
schedule  status,  data  accounting  and  data  quality  and  usage  reports. 

7.4.5  Level  Zero  Processing  Facilities  (LZPF's) 

Level  zero  processing  in  the  proposed  design  consists  of  the  following 
functions : 

• Capture  of  data  routed  as  CCSDS  virtual  channels  from  the  DHC 

• Reed-Solomon  decoding 

• Extraction  of  CCSDS  telemetry  packets 

• Merging  of  tape  recorder  data  and  deletion  of  redundancies 

• Fill  insertion 

• Data  completeness  and  quality  accounting  on  a transfer  frame  and 
telemetry  packet  bases 

• Routing  of  real-time  payload  science  and  engineering  data 

• Store  and  forward  service  for  non-real-time  data 


Payload  data  level  zero  processing  is  performed  at  three  sites  in  the  strawman 
design,  GSFC,  LARC,  and  JPL.  Most  level  zero  processing  is  performed  at  GSFC, 
in  particular  low— rate  data  passes  through  GSFC  prior  to  delivery.  This 
includes  real-time  payload  engineering  data  routed  to  the  payload  OCC's,  but 
not  core  engineering  data  which  is  directly  routed  to  the  SSOCC  and  platform 
OCC's  by  the  DHC.  In  particular,  all  Independent  Customers  receive  their  data 
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through  the  GSFC  LZPF.  Other  LZPF's  are  located  at  NASA  facilities  sponsoring 
particularly  high  bandwidth  experiments  which  necessitate  local  access  to 
Level  Zero  working  data  stores  for  high  level  processing.  In  the  Langley  data 
base  the  only  other  candidate  facilities  are  JPL  and  LARC.  However,  the  LZPF 
design  presented  here  may  be  replicated  at  other  centers  as  requirements 
change.  It  also  may  be  feasible  to  colocate  the  LARC  LZPF  with  the  GSFC  LZPF. 

The  design  presented  in  thi3  section  is  directed  toward  the  GSFC  LZPF  which 
supports  both  high  and  low  rate  Level  Zero  processing.  However,  all  elements 
of  the  design  are  appropriate  (in  scaled  down  form)  to  the  other  LZPF's. 

7.4.5. 1 Interface  Description 

The  functional  interfaces  for  the  LZPF's  which  are  illustrated  on  figure 
7.4. 1-1,  are  discussed  in  the  sections  below. 

7.4.5. 1.1  Data  Handling  Center 

Downlink  data  in  CCSDS  transfer  frame  is  routed  directly  from  the  DHC  to  the 
LZPF's.  It  is  assumed  that  the  data  distribution  network  delivers  transfer 
frames  in  exactly  the  same  form  as  they  are  passed  to  the  communications  ports 
at  the  DHC  with  all  network  artifacts  removed.  The  LZPF  sees  a stream  of 
CCSDS  transfer  frames  identical  to  those  which  arrive  at  the  NGT  interface. 
Optionally,  Reed-Solomon  encoding  may  be  rechecked  by  the  LZPF  and  appropriate 
error  correction  applied  to  correct  for  data  distribution  network  noise. 
Expected  data  rates  are  as  follows: 

GSFC  — High  rate  data  125  megabits/sec.  average,  600.00  megabits/sec.  peak 
GSFC  — Low  rate  data  5.2  megabits/sec.  average 

JPL  — High  rate  data  18.75  megabits/sec.  average,  300  megabits/sec.  peak 
LARC  — High  rate  data  50.00  megbits/sec.  peak 
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7.4.5. 1.2  Payload  Operations  Control  Centers 


Payload  OCC's  receive  all  their  engineering  data  through  the  GSFC  LZPF  either 
as  real-time  data  or  in  store  and  forward  mode.  Audio  and  video,  however,  are 
received  directly  from  the  DHC.  It  should  be  understood  that  the  SSOCC,  COPCC, 
and  POPCC  communicate  directly  with  the  DHC  and  receive  their  engineering  data 
directly  through  dedicated  virtual  channels. 

7.4.5. 1.3  Engineering  Data  Centers 

Communications  with  the  EDC's  will  primarily  be  to  retrieve  archived  ancillary 
data.  This  will  be  performed  through  the  packet  network. 

7.4.5. 1.4  Customer  RDC's 

Customer  RDC's  receive  their  data  directly  from  the  LZPF's  through  packet 
network  or  high  rate  circuit  switched  links.  Requests  for  data  are  mediated 
through  an  Access  Control  processor  which  isolates  the  requestor  from  Level 
Zero  production  activities.  In  many  cases  the  RDC's  will  be  collocated  with 
the  LZPF's  and  direct  high— bandwidth  access  to  Level  Zero  working  stores 
through  a LAN  will  be  feasible. 

7.4.5. 1.4  Independent  Customers 

Independent  Customers  will  receive  data  directly  from  the  LZPF's  using 
procedures  similar  to  Customer  RDC's. 

7. 4. 5. 1.5  Ground  Services  Center 

The  LZPF  communicates  with  the  GSC  to  coordinate  schedule  for  high— bandwidth 
communications  links  and  to  occasionally  request  retransmission  from  the  DHC. 
The  LZPF  also  delivers  accounting  and  quality  data  to  the  GSC. 
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7. 4. 5. 2  Function  Description 


The  LZPF  is  the  SSDS  node  which  captures  data  and  prepares  it  for  distribution 
in  either  real-time  or  store  and  forward  mode.  Processing  paths  are  somewhat 
different  for  low  and  high  rate  data.  In  the  stawman  design,  it  will  perform 
the  following  functions: 

7. 4. 5. 2.1  Preprocessing 

Reed-Solomon  Error  Correction  — a repetition  of  the  correction  applied  at  the 
DHC  to  CCSDS  transfer  frames  to  reduce  noise  introduced  by  the  DHC-LZPF  link. 

Merging  of  recorder  data  — ordering  of  data  and  deletion  of  redundancies,  but 
not  including  bit  reversal  since  the  onboard  recorder  is  implemented  in 
eraseable  optical  disk  technology. 

Data  completeness  and  quality  accounting  — information  provided  both  to  users 
of  data  and  to  the  GSC 

7. 4. 5. 2. 2 Real-Time  Data  Routing 

High  Rate  Data  Routing  — to  provide  direct  routing  of  high  rate  data  through 
the  circuit  switched  links 

Low  Rate  Data  Routing  — to  provide  direct  routing 

7. 4. 5. 2. 3 Short  Term  Storage  and  Forwarding 

Data  Capture  — to  store  data  prior  to  production  or  quick  look  processing  and 
to  capture  real-time  data  for  temporary  backup 

File  Management  — to  manage  both  offline  and  online  storage  file  systems 

Batch  Forwarding  — to  group  data  into  production  and  quicklook  batches  and 
route  them  to  appropriate  destinations 
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7. 4. 5. 2. 4 Access  Control 


Data  Access  Authorization  — to  control  external  access  to  Level  Zero  Data  and 
prevent  external  interference  with  production  operations  f 

7. 4. 5. 2. 5 Facility  Management 

Configuration  Management  — to  manage  computer  and  communications  gateway 
configuration 

External  Coordination  — to  accept  schedules  from  and  to  coordinate  with  other 
SSDS  elements  through  the  GSC 

Resource  Scheduling  — to  coordinate  internal  LZPF  facility  usage  and  balance 
processing  and  bandwidth  loading  among  processing  elements 

Cold  Start,  Restart,  and  Switchover  — to  manage  startup,  restarts,  and 
switchovers 

7. 4. 5. 3 Design  Approach 

This  section  discusses  a high  level  design  approach  to  the  LZPF's.  The 
following  key  assumptions  were  made: 

• Data  is  delivered  from  the  DHC  to  the  LZPF  in  CCSDS  transfer  frame 
format  with  no  network  artifacts  added. 

• No  bit  reversal  of  tape  recorder  data  is  necessary. 

• Low  rate  data  is  organized  as  CCSDS  telemetry  packets  within  one  or 
more  dedicated  virtual  channels. 

• Access  to  Level  Zero  processed  data  is  through  either  a packet 
network  or  through  dedicated  high  rate  links. 

• All  requests  for  data  retrieval  or  reconf iguration  are  routed  through 
the  packet  network . 
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A function  diagram  for  the  LZPF'  appears  as  figure  7. 4. 5. 3-1.  Briefly,  the 
system  is  organized  around  a high  bandwidth  LAN  (100  megabits/sec)  which 
serves  routing  system  for  commands,  interprocessor  communications,  and  low 
rate  data.  High  rate  data,  however,  is  not  carried  on  the  LAN.  It  instead 
passes  through  separate  links  managed  by  a pool  of  high-speed  I/O  processors 
and  storage  controllers.  External  access  to  Level  Zero  data  is  controlled 
through  an  Access  Control  Processor  which  is  connected  directly  to  the  packet 
network.  The  Access  Control  Processor  provides  a degree  of  isolation  which  is 
essential  to  the  health  of  the  LZPF  since  the  high  speed  processors  likely  to 
be  used  to  handle  data  typically  have  operating  systems  which  provide  poor 
data  security.  Store  and  forward  data  requests  are  handled  through  an  Archive 
Processor  which  either  arranges  a direct  high— bandwidth  link  from  the  storage 
system  or  passes  low  rate  data  through  the  LAN  directly  to  the  Access  Control 


Figure  7.4.5.3-1.  Typical  Level  Zero  Processing  Facility 
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Processor.  The  Facility  Management  Processor  provides  system  reconf iguration 
capabilities,  and  serves  to  implement  system  restarts  and  failovers. 

This  configuration  is  similar  to  the  CDC  Cyber/Cyberplus  processor  being 
considered  for  the  GSFC  Advanced  Telemetry  Processor  program  (with  a number  of 
special  purpose  processors  linked  in  through  the  high  bandwidth  LAN). 

However,  there  are  quite  a few  architectural  alternatives  which  provide 
similar  types  of  high  bandwidth  data  paths  (albeit  with  different 
cost/performance  ratios). 

The  next  few  sections  describe  some  of  the  processing  functions  and  associated 
data  flow. 

7. 4. 5. 3.1  High  Rate  Data  Real-Time  Processing 

We  describe  the  end-to-end  data  flow  and  the  steps  required  to  initiate  the 
processing.  Initially,  high— rate  real  time  processing  is  set  up  through  a 
scheduling  request  sent  by  the  customer  to  the  OCC.  The  GSC  is  responsible 
for  arranging  the  link  from  the  payload  through  TDRSS  through  the  DHC  to  the 
LZPF  to  the  customer  facility  receiving  the  data.  This  is  accomplished 
through  reconf iguration  messages  to  the  SSDS  components  and  the  NCC.  Full 
automation  of  this  process  through  a network  call  setup  protocol  is  highly 
desireable.  We  assume  that  the  customer  has  arranged  appropriate  high  rate 
tail  circuits  to  handle  the  communication  with  the  LZPF. 


As  CCSDS  transfer  frames  arrive  at  the  High  Rate  Network  Interface,  they  are 
decoded  at  the  front  end  and  sent  to  one  or  more  dedicated  I/O  processors. 
CCSDS  transfer  frame  headers  are  stripped,  telemetry  packets  are 
reconstructed,  data  quality  and  completeness  information  is  appended,  fill  is 
inserted  where  necessary,  and  appropriate  transport  information  is  appended. 
Data  is  then  routed  to  the  appropriate  output  port.  The  telemetry  packets  are 
also  routed  to  an  appropriate  storage  channel,  depending  on  customer 
requirements  for  additional  backup  and/or  store  and  forward  service. 
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7. 4. 5. 3. 2 Low  Rate  Data  Real-Time  Processing 


Low  rate  data  is  subject  to  a somewhat  more  complex  process  since  multiple  low 
rati  experiments  are  multiplexed  on  a single  CCSDS  virtual  channels.  However, 
scheduling  of  circuit  links  through  the  GSC  is  not  required.  The  low-rate 
real-time  customer  first  enables  his  payload  through  appropriate  interaction 
with  the  DHC  command  uplink  and  mission  scheduling  system.  He  then  links  to 
the  LZPF  through  the  packet  network.  Access  to  the  LZPF  is  controlled  through 
the  Access  Control  Processor  which  implements  secure  access  to  LZPF  facility 
(security  controlled  by  the  GSC).  The  customer  then  sends  a message 
indicating  the  payload  to  which  he  wishes  to  link.  This  is  checked  against 
authorization  tables  sent  from  the  GSC  and  serves  to  initiate  a process  which 
routes  low-rate  telemetry  data  to  the  customer  through  the  packet  network. 

Several  input  virtual  channels  are  devoted  to  low-rate  data.  The  initial 
processing  is  similar  to  high-rate  processing.  As  CCSDS  transfer  frames 
arrive  at  the  High  Rate  Network  Interface,  they  are  decoded  at  the  front  end 
and  sent  to  one  or  more  dedicated  I/O  processors.  CCSDS  transfer  frame 
headers  are  stripped,  telemetry  packets  are  reconstructed , data  quality  and 
completeness  information  is  appended,  and  fill  is  inserted  where  necessary, 
and  appropriate  transport  information  is  appended.  If  a real-time  low  rate 
link  has  been  initiated  the  telemetry  packets  are  then  routed  through  the  high 
bandwidth  LAN  to  the  Access  Control  Processor  which  then  routes  them  through 
the  packet  network  to  the  customer.  The  telemetry  packets  are  also  routed  to 
an  appropriate  storage  channel,  depending  on  customer  requirements  for 
additional  backup  and/or  store  and  forward  service. 


7. 4. 5. 3. 3 Store  and  Forward  Processing 

When  data  are  not  required  in  real-time,  they  are  routed  to  store  and  forward 
processing  which  provides  boti  quicklook  and  production  services.  Front  end 
processing  is  identical  to  real-time  processing.  As  telemetry  packets  are 
received  they  are  grouped  into  batches  and  stored.  Scheduled  production  runs 
merge  batches  of  telemetry  packets  received  in  real-time  and  through  recorder 
dumps,  removing  redundancies,  and  inserting  fill  wherever  necessary.  The 
batches  are  routed  to  storage  and  a batch  file  catalog  is  maintained  through  a 
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standard  DBMS  product  running  on  an  Archive  Processor.  A user  requiring  a 
stored  data  file  logs  in  through  the  packet  network,  is  connected  to  the 
Archive  Processor  which  supports  browsing  of  file  catalog  data  base.  Data 
transfer  can  then  be  requested  according  to  standard  services  which  support 
access  to  data  subsets  by  time  interval  and  experiment.  Transfer  is  supported 
through  high-rate  or  low-rate  packet  services  as  appropriate. 

7.4.6  Control  Centers 

The  Space  Station  Program  control  centers  consist  of  the  Space  Station 
Operations  Control  Center  (SSOCC),  the  Co-orbiting  Platform  Control  Center 
(COPCC) , and  the  Polar  Orbiting  Platform  Control  Center  (POPCC).  The  design 
assumes  that  the  SSOCC  is  located  at  JSC,  and  the  COPCC  and  POPCC  are  located 
at  GSFC.  The  following  sections  apply  generally  to  all  the  Centers  unless 
otherwise  noted. 

The  Control  Centers  must  be  capable  of  supporting  all  mission  phases. 
Prelaunch  activities  include  the  integration  and  test  of  the  space  element 
and  platform  payloads,  and  flight  and  ground  crew  training.  Launch  phase 
activities  include  the  monitoring  and  control  of  the  Space  Station  buildup 
and  deployment  of  the  platforms.  On-orbit  operations  include  the  supervisory 
control  of  the  space  element's  autonomous  operations  during  normal  and 
emergency  operations,  payload  integration  and  checkout,  servicing,  and  the 
retrieval  of  platforms.  The  platform  control  centers  must  also  have  the 
capability  of  simultaneously  supporting  multiple  platforms  in  various  mission 
phases . 

7.4.6. 1 Interface  Description 

The  functional  interfaces  of  the  Control  Center  are  listed  in  Table 

7.4.6. 1-1.  The  interface  descriptions  are  the  same  for  the  SSOCC,  COPCC,  and 

POPCC  except  where  noted  otherwise. 

The  traffic  along  these  interfaces  tends  to  be  low  in  volume  except  for  the 
uplink  and  downlink  data.  A3  noted  in  Table  5-4,  the  Space  Station  core 
telemetry  rate  is  assumed  to  be  256  kbps,  and  the  command  rate  is  4 kbps. 

For  platforms,  a telemetry  rate  of  64  kbps  and  a command  rate  of  4 kbps  were 
assumed.  The  voice  and  video  rates  are  undefined. 
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Table  7. 4. 6. 1-1 

Control  Center  Functional  Interfaces  to  Ground  Elements 


Element 

Interface  Traffic 

Purpose 

Space  Element 
(via  OHC) 

Core  Uplink 

Controls,  voice,  video 

Core  Downlink 

Status,  voice,  video 

Schedules 

Resource  and  operating  events 
scheduling 

GSC 

Schedules/Status 

Communications/common  resource 
schedule  coordination 

POCC's 

Schedule  Requests 

Mission  scheduling  of  Customers 
payload  mode  changes 

Schedules/Status 

Mission/payload  schedule 
coordination 

Flight  Dynamics 
Facility 
(COPCC,  POPCC) 

Orbit/Attitude 

Mission  planning 
Verification  of  onboard 
comps,  (backup) 

EDC 

Core  Uplink, 
Computed  Data 

Archival  storage 

Queries/Responses 

Archival  retrieval 

Schedules/Status 

Ground  resource  mgmt. 

DSIT 

S/WLoads 

OCC  modifications 
Onboard  s/w  modifications 
Development  — testing 

SlmulatlonData 

Flight  controller  and  crew 
training  Integration  testing 

Other  CC: 

COPCC 

(SSOCC) 

Schedule/Status 

Coordination  of  COP  servicing 
and  utilization  of  SS  resources 

STS  MCC 

Schedule/Status 

Coordination  of  shuttle  visits 

OMV/OTV 
Remote  Ops.  CC 

Schedule/Status 

Coordination  of  servicing 
(COPCC/POPCC) 

Coordination  of  prox.  and  remote 
ops.  (SSOCC) 


Free  Flyer  CC 
(SSOCC) 


Schedule/Status 
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Coordination  of  prox.  ops 


7. 4. 6. 2 Function  Description 


The  subsections  of  7. 4. 6. 2,  discuss  the  generic  Control  Center  systems  which 
accomplish  the  functions  identified  in  Table  7. 2. 3-1.  These  Control  Center 
systems  for  the  Space  Station  Program  will  significantly  differ  from  those  of 
previous  spacecraft  programs  in  the  following  ways: 

• the  reduction  of  processing  required  due  to  the  greater  autonomy  of 

% 

the  space  element  from  the  ground  systems; 

• the  reduction  of  processing  required  to  perform  tracking  data 
analysis  due  to  the  reduction  of  navigation  data  sources  employed 
(GPS  and  TDRSS),  and  the  improvement  in  ground  navigation  techniques; 

• the  addition  of  an  interface  to  the  ground  and  onboard  scheduling 
systems  for  the  control  of  mission  operations; 

• the  increase  of  processing  required  for  the  automation  of  some  ground 
support  functions. 

7. 4. 6. 2.1  Communications 

The  Communications  system  provides  the  interface  to  the  wide  area  and  local 
area  networks  connecting  the  Control  Center  to  the  other  SSPE's.  The  system 
provides : 


a.  External  Interface  management 

• Support  communication  link  monitoring 

• Provide  transmission  error  detection 

• Support  protocols  requiring  acknowledgements  and  retransmissions 

• Provide  performance  monitoring  data  to  GSC 

b.  Data  Processing 


• Perform  required  preprocessing  (e.g.data  extraction  from  CCSDS 
packets) 

• Route  data  to  processing  systems 
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Intra-Center  Distribution 


c . 


• Voice  subsystem 

• Video  subsystem 

• Local  area  networks 

7.4.6. 2,2  Monitor  and  Control 

Monitor  and  control  processing  provides  support  for  real-time  operations  and 
trend  analysis.  For  initial  Station  operational  phases  (i.e. 
assembly/activation  and  buildup  phases),  the  Control  Center  provides 
monitoring  and  primary  control  of  onboard  systems.  As  the  onboard  systems  are 
implemented  and  mature,  several  of  the  initial  ground  telemetry  functions 
take  on  a supervisory  mode  of  operation. 

The  capability  to  perform  special  computations,  limit  sensing,  logical 
processing,  and  trend  analysis  of  real-time  and  historical  core  engineering 
data  are  provided  in  support  of  monitoring  and  control  of  on-board  systems. 
Example  system  capabilities  are: 

• Monitor  and  Control  of  onboard  Power  systems 

- Electrical  power  generation 

- Power  distribution 

- Power  storage 

- Element  lighting 

• Monitor  and  Control  of  onboard  Mechanical  systems 

- Docking/berthing  systems 

- Hatches 

- Vent  Doors 

- Solar  array  booms 

- Servicing  fixtures 

- Manipulators 
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Verification  of  command  receipt  and  execution  is  also  provided  through  the 
monitoring  of  the  downlinked  stored  program  command  buffers  and  the  command 
logs . 

7. 4. 6. 2. 3 Trajectory 

Trajectory  computations  and  display  processing  are  provided  by  the  trajectory 
system  in  support  of  planning  and  mission  operations.  The  Control  Center's 
trajectory  system  works  in  coordination  with  onboard  avionics  systems  to 
provide  navigation,  guidance,  attitude  control,  traffic  control,  tracking, 
and  time  management.  The  Trajectory  system  is  capable  of  accepting  tracking 
data  from  the  Global  Positioning  System  (GPS)  and  TDRSS . 

The  Trajectory  system's  planning  functions  are: 

a.  Receive  planning  data  for  mission  segments 

• Nominal  state  vectors/timelines  from  flight  design  activity 

• Schedule  events  data  from  mission  scheduling  activity 

b.  Generate  trajectory  profile  data  for  mission  segments 

• Ephemeris 

• Orbital  events  data  (AOS/LOS,  maneuvers,  rendezvous  times, 

sun/moon  lighting,  etc.) 

c.  Provide  display  capability  for  planning  review  of  trajectory  data 

The  following  Trajectory  system  capabilities  are  provided  during  mission 
operations  in  support  and  backup  of  the  onboard  system: 

a.  Receive  and  process  tracking  data 

• TDRSS  S-band  tracking 

• • GPS  tracking 

b.  Generate/maintain  trajectory  profile  data 

• Ephemeris 

• Orbital  events  data  (AOS/LOS,  maneuvers,  rendezvous  times, 

sun/moon  lighting,  etc.) 
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c.  Generate/maintain  maneuver  planning  data 

• Attitude  maneuvers 

• Rendezvous/proximity  OPS  maneuvers 

• Orbital  maintenance  maneuvers 

d.  Generate/maintain  general  on-orbit  computation  data 

• Constellation  relative  states  (including  line-of-sight 
computations  for  SS  to  platforms) 

• Mass  properties/consumables 

• Onboard/ground  navigation  state  comparisons 

e.  Provide  display  capability  for  real-time  monitoring/on-demand  review 
of  current  trajectory-related  data. 

g.  Provide  for  short-term  retention  of  trajectory  data 

• Tracking  data 

• As-flown  orbital  events  data 

g.  Perform  orbital  analyses  (as  required) 

• Quality  of  trajectory  predictions 

• "Best  estimate"  trajectory  reconstructions  (of  specified 
orbit/mission  segments 

i.  Prepare  mission  trajectory  data  for  archival  storage  in  the  EDC 


7 . 4 . 6 . 2 . 4 Command 
The  Command  system: 

• Issues  real-time  and  stored  program  commands  for  supervisory  control 
of  onboard  subsystems  during  operations; 

• Supports  the  building  of  single-stage  and  two-stage  commands  for 
real-time  operations  and  planning 


7-67 


• Provides  command  validation,  safing,  and  checking  to  ensure  safety, 
effectivity,  schedule  compliance,  etc. 

• Provides  for  the  loading  of  onboard  computers  (to  main  or  mass 
memory) 

7. 4. 6. 2. 5 Control  Center  Facility  Management/Scheduling 

The  higher  level  interface  for  this  system  is  the  Mission  Scheduling  System 
and  the  lower  level  interface  is  to  the  subelements  of  the  Control  Center. 

The  Facility  Management  system  manages  the  Control  Center's  hardware, 
software,  and  data  elements.  Its  functions  include: 

a.  Configure  the  Control  Center  to  provide  scheduled  services 

b.  Interpret  status  data  and  issue  appropriate  controls  to  ensure 
optimal  functionality 

c.  Ensure  that  the  hardware  and  software  within  each  node  are 
appropriate  to  support  its  function 

d.  Verify  authorization  and  provide  access  control  to  nodal  software 
loads  based  upon: 

• operator  identification 

• functions  (e.g.  flight  director,  payloads  officer) 

• mission  phase  (e.g.  rendezvous,  deployment) 

• activity  (e.g.  mission  support, training) 

e.  Provide  real-time  and  historical  ground  system  status 

f.  Monitor  system  maintenance 

The  Facility  Scheduling  system  provides  the  interface  to  the  Mission 
Scheduling  System  and  performs  the  scheduling  of  the  Control  Center.  The 
Scheduling  system  provides  the  coordination  of  mission  operations  with 


7-68 


facility  operations  such  as  training,  installation  of  new  systems, 
hardware/software  updates,  and  maintenance. 

7. 4. 6. 2. 6 Mission  Scheduling 

The  Mission  Scheduling  Systems  are  responsible  for  the  generation, 
maintenance,  and  distribution  of  the  Operating  Events  Schedule  (OES).  There 
are  two  systems:  the  Space  Station  Mission  Scheduling  System  at  the  SSOCC 

and  the  Platform  Mission  Scheduling  System  at  the  COPCC/POPCC.  Both  systems 
generate  bi—  weekly  schedules;  however,  the  SSOCC  system  also  coordinates 
with  an  onboard  scheduling  system  which  supports  the  crew  in  the  neai — term 
(1-2  days)  refinement  of  the  OES.  It  is  proposed  that  platform  scheduling 
be  performed  entirely  on  the  ground;  however,  this  design  is  sensitive  to  an 
assumption  that  communications  coverage  is  sufficient  to  support  a 
ground-based  system  without  seriously  inhibiting  the  autonomy  of  the 
platform  and  payloads.  Both  systems  process  ground-originated  schedule 
change  requests  on  the  ground. 

The  following  design— level  functions  of  the  Mission  Scheduling  System  are 
derivatives  of  functions  3.2,  Develop  Short  Term  Schedule,  and  3.3,  Develop 
Operating  Events  Schedule.  These  functions  are  common  to  both  the  Space 
Station  and  Platform  Mission  Scheduling  Systems  except  where  noted  otherwise. 

a.  Data  Base  Generation 

o Provide  services  for  multiple  users  for  local/remote  entry  and 
modification  of  data 

o Support  a user  friendly  interface  — menus,  help  functions, 
high  level  (or  natural)  query  language,  checking/validating  of 
entries 

o Provide  configuration  management  for  various  levels  of  file 
certification  — development  through  master  operating  files. 

Table  7. 4. 6. 2. 6-1  lists  some  of  the  attributes  defined  in  the  Mission 
Scheduling  Data  Base  and  their  sources. 


7-69 


Table  7. 4. 6. 2. 6-1 

Mission  Scheduling  Data  Base:  Attributes  Definition 


DEFINED  ATTRIBUTES 


SOURCE 


• Mission  Requirements  Schedule  - major  • Space  Station  Program 

events  such  as  shuttle  visits,  extensive 
modifications/upgrades,  crew  changes, 

gross  scheduling  of  reboosts,  etc. 

• Manifest  - contractual  agreements  with  • Space  Station  Program 

customers. 


e Characterization  of  payload  modes  - 
required  resources,  constraints, 
restrictions  (components  of  vector 
triplets) 


• Mission  Scheduling  System 
(Internal)  — customer/NASA 
Inputs 


• Characterization  of  core  operations  that 
require  scheduling,  such  as  maintenance, 
docking/servicing,  ventings,  maneuvers 


• Mission  Scheduling  System 
Internal)  — NASA  Inputs 


• Characterization  of  available  resources  - 
crew  time,  communications,  power,  data 
system,  ground  support  such  as  POCC 
availability 

• Trajectory  profiles  - ephemerls,  orbital 
events  (AOS/LOS,  maneuvers,  rendezvous 
times,  sun/moon/earth  viewing,  lighting, 
etc.) 

t Priority  rulesets 


• Mission  Scheduling  System 
(Internal)  — NASA  Inputs 


• Flight  Design  Activity  - 
SSOCC 

Flight  Dynamics  Facility  - 
COPCC/POPCC 

• Mission  Scheduling  System 
(Internal)  — NASA  Inputs 
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b.  Operating  Events  Schedule  Generation  and  Maintenance 

• Resolve  conflicts  through  iteration  and  operator  interaction 
to  achieve  a feasible  (as  opposed  tcf  optimal)  schedule 

• Support  hypothetical,  "what  if,"  scheduling 

• Support  multiple  users  for  interactive,  electronic, 
local/remote  entry  of  schedule  change  requests 

• Support  rapid  replanning  for  unique  payload  opportunities 

• Process  schedule  change  requests  and  provide  dispositions, 
which  include  alternative  options  if  request  cannot  be  met 

• Coordinate  schedule  changes  with  the  onboard  scheduling  system 
and  crew  (Space  Station  only)  including  the  incorporation  of 
onboard-originated  changes 

• Coordinate  schedule  changes  that  impact  joint  operations 
involving  other  Space  Elements 

• Coordinate  communication/common  resource  support  with  the 
Ground  Services  Center 

• Monitor  status  returned  from  onboard  and  ground  facility  and 
resource  management  functions  and  adjust  schedule  as  required 

• Support  maintenance/development  of  the  scheduling  system,  e.g. 
modifications  to  rulesets 

The  timeliness  of  the  system's  response  to  schedule  change  requests  depends 
upon  the  characterization  of  the  requested  operation  and  the  breadth  of  its 
impact  to  other  operations,  i.e.  on  the  amount  and  nature  (automated  or  human 
decision)  of  conflict  resolution  required.  For  example,  the  response  time 
should  be  in  the  order  of  seconds  to  a simple  activate/deactivate  request  for 
a payload  whose  mode  is  characterized  as  requiring  minimal  resources, 
offering  no  interference  to  other  operations,  and  posing  no  hazards. 

c.  Operating  Events  Schedule  Distribution 

• Uplink  modified  schedule  to  onboard  system 

• Distribute  schedule  reports  to  ground  users  and  facility 
managers  — schedule  execution  status,  schedule  changes, 
opportunity  alerts,  orbital  events,  etc. 
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7.4.6, 3 Design  Approach 


The  design  approach  for  control  centers  first  addresses  the  generic  design 
drivers  common  to  all  control  centers.  The  unique  design  drivers  for  each 
control  center  are  then  described.  The  primary  goal  is  to  produce  a general 
design  that  is  common  to  all  control  centers  while  satisfying  the  unique 
design  drivers  of  each  control  center.  A familiarity  with  the  functions 
described  in  section  7. 4. 6. 2 is  necessary  in  order  to  understand  the  design 
approach  as  well  as  the  architecture . 

7. 4. 6. 3.1  Generic  Design  Drivers 

The  following  items  represent  common  design  drivers  for  the  SSOCC  as  well  as 
the  POPCC  and  COPCC.  These  design  drivers  focus  on  the  changing  technology 
and  the  evolution  of  requirements  over  the  life  of  the  project. 

• FLEXIBILITY  - This  quality  allows  a control  center  to  meet  changing 
needs  in  a timely  and  cost  effective  manner. 

• TECHNOLOGY  INSERTION  - As  technology  changes,  upgrades  should  be 
possible  without  requiring  a major  redesign  of  the  control  center. 

• GROWTH  - As  functions  become  mature  they  usually  increase  their 
resource  requirements . While  it  is  difficult  to  size  all  resources 
with  great  precision,  a good  design  can  allow  for  growth  without 
excessive  expense  or  initial  over  specification. 

• LIFE  CYCLE  COST  - The  cost  of  a system  reaches  far  beyond  the 
purchase  price.  The  operating  costs  must  be  considered  in  order  to 
provide  a cost  effective  solution. 

• CORE  DATA  RETRIEVAL  VIA  EDC  - In  order  to  avoid  excessive  storage 
costs,  the  EDC  will  be  the  storage  facility  of  core  engineering  data 
for  all  users . 
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• AUTOMATION  - The  system  should  utilize  technologies  that  allow 
equipment  to  perform  an  increasing  number  of  tasks  in  order  to 
improve  productivity  and  reduce  staffing. 

• COMMERCIAL  OFF  THE  SHELF  (COTS)  - The  use  of  standard  commercial 
products  in  place  of  custom  built  equipment  is  highly  desirable. 

• REUSABILITY  - The  design  should  utilize  hardware  and  software 
developed  through  other  projects  when  possible 

• CONTINGENCY  SUPPORT  - Even  though  the  Space  Station  and 
platforms  are  designed  to  be  highly  autonomous,  the  Control  Centers 
must  retain  the  capability  to  provide  critical  support  in  the  event 
of  the  failure  of  the  onboard  systems. 

7. 4. 6. 3. 1.1  SSOCC  Design  Drivers 

With  the  control  centers  for  both  Space  Station  and  shuttle  located  at  the 
Johnson  Space  Center,  commonality  is  highly  desirable.  The  major  areas  of 
compatibility  are  addressed  as  design  drivers  for  the  SSOCC. 

• COMPATIBILITY  WITH  MCC/ERRP  - The  Mission  Control  Center  is  being 
upgraded  under  the  current  EQUIPMENT  REPLACEMENT  and  REFURBISHMENT 
PLAN.  This  plan  provides  for  the  replacement  of  old  equipment  with  a 
technology  upgrade  in  about  the  same  time  frame  as  the  SSOCC 
delivery.  The  result  is  the  development  of  two  facilities  with  the 
same  technologies.  Compatibility  can  be  achieved  without  sacrificing 
state— of— the— art  designs.  Also,  the  potential  for  reusability  is  very 
high  between  these  projects. 

• FCR/MPSR  SUPPORT  CONCEPT  - The  support  for  the  shuttle  is  provided 
through  a combination  of  Flight  Control  Rooms  (FCR)  and  Multi-Purpose 
Support  Rooms  (MPSR).  The  MPSRs  provide  support  to  the  FCR 
activities  with  the  final  authority  for  operations  resting  with  FCR 
personnel.  In  the  case  of  routine  operations  or  minimal  activity 
periods,  support  may  be  provided  by  a single  FCR  or  MPSR.  This 
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allows  resources  to  be  used  for  planning  or  other  activities  when  not 
directly  supporting  a mission.  It  is  highly  desirable  to  design  the 
SSOCC  around  this  FCR/MPSR  concept. 

• MCC  INTER-OPERABILITY  - With  the  design  drivers  of  compatibility  and 
the  FCR/MPSR  concept,  inter-operability  is  simply  the  next  step. 
Inter-operability  allows  MCC  and  SSOCC  resources  to  be  interchanged. 
This  reduces  operational  concerns  about  the  training  of  controllers 
and  scheduling  of  ground  resources.  The  current  operations  concepts 
for  the  SSOCC  are  generally  the  same  as  those  of  the  MCC.  The 
possibility  of  using  MCC-developed  software  and  equipment  for  the 
SSOCC  is  virtually  assured  under  inter— operability . 

7. 4. 6. 3. 1.2  COPCC/POPCC 

The  design  drivers  for  the  various  platform  control  centers  are  similar  to 
those  of  the  SSOCC.  These  control  centers  will  be  located  at  the  Goddard 
Space  Flight  Center.  While  the  magnitude  of  the  support  requirements  for  a 
platform  differ  from  those  of  the  Space  Station,  the  same  concepts  of  support 
are  applicable. 

• SUPPORT  ROOM  PER  PLATFORM  - Since  the  number  of  control  positions 
necessary  for  a platform  are  smaller  than  those  for  a manned  vehicle, 
a single  support  room  per  platform  should  be  sufficient.  This 
concept  allows  for  incremental  growth  as  the  number  of  platforms 
increases . 

• SUPPORT  ROOM  INTER-OPERABILITY  - The  potential  for  cost  savings 
through  inter-operability  is  great.  The  majority  of  the  development 
costs  are  absorbed  by  the  first  support  room.  The  remaining  rooms 
should  be  mostly  copies  of  the  first.  The  remaining  rooms  should  be 
made  operational  in  less  time  than  the  first  by  using  compatible 
equipment  and  software.  Inter— operability  also  allows  an  unused  room 
to  act  as  a backup  for  other  active  support  rooms.  Personnel  can  be 
moved  from  one  support  room  to  another  with  little  or  no  retraining 
concerning  facilities. 
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7. 4. 6. 3. 2 Generic  Configuration  and  Architecture 


With  most  of  the  design  drivers  being  generic  in  nature,  a generic 
configuration  and  architecture  is  a desirable  solution.  A common  philosophy 
makes  the  actual  designs  of  the  control  centers  consistent  and  allows 
consideration  of  common  equipment  and  software  procurements . The 
configuration  and  architecture  are  based  on  the  following  concepts: 

• Functional  Allocation  and  Physical  Partitioning 

• Network/Workstation  Concept 

A great  deal  of  the  effort  in  the  design  process  involves  defining  functions 
and  determining  methods  of  implementation.  The  goal  of  the  designer  is  that 
of  isolating  a function.  This  is  generally  accomplished  by  determining  the 
inputs  and  the  products  along  with  the  necessary  transformations  of  inputs 
to  generate  the  products.  Understanding  the  relationships  of  all  functions 
in  the  system  gives  rise  to  functional  allocation.  In  general,  the 
allocation  is  made  by  a global  or  local  qualification.  A global  function 
provides  a service  or  product  necessary  for  all  or  most  of  its  related 
functions.  In  the  design  of  a spacecraft  control  center,  the  air-to-ground 
communications  equipment  represents  a global  function.  In  contrast,  the 
monitoring  of  a spacecraft  subsystem  is  a local  function.  Local  functions 
tend  to  be  unique  activities  in  the  system  while  global  functions  are  of 
general  interest. 

Until  recently,  the  functional  allocation  represented  the  major  effort  in  the 
design  process.  Once  all  of  the  functions  are  sized,  the  only  thing  left  to 
do  is  select  a computer  and  begin  development.  Over  the  last  few  years 
communications  and  small  computers  have  evolved  to  the  point  of  providing  an 
alternative  to  the  large,  multi-user  mainframe.  It  is  now  reasonable  to 
consider  hosting  a function  in  its  own  computer  and  linking  these  computers 
together  by  some  type  of  network.  This  process  is  called  physical 
partitioning.  The  use  of  physical  partitioning  can  provide  many  important 
advantages.  These  include: 

• Stable  interfaces  on  physical  boundaries 
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• Ease  of  growth 

• Improved  capability  to  utilize  new  technologies  after  implementation 

• Improved  flexibility 

• Better  performance 

• Possible  cost  reductions 

Functional  allocation  and  physical  partitioning  are  not  without  dangers. 
Improper  hosting  of  functions  can  result  in  poor  performance  and  excessive 
equipment  and  expense.  However,  the  flexibility  of  the  design  will  generally 
allow  these  errors  to  be  corrected  without  a total  redesign  or 
reimplementation.  Schedule  and  budget  concerns  strongly  encourage  proper 
allocation  and  partitioning  prior  to  implementation. 

The  configuration  and  architecture  used  to  satisfy  the  needs  of  the  control 
centers  is  based  on  the  concept  of  networks  and  workstations.  The  basic 
implementation  involves  a group  of  processors  (workstations)  connected  by 
means  of  a Local  Area  Network  (LAN).  Most  workstations  are  manned  by  flight 
controllers.  But  a workstation  does  not  have  to  be  manned  and  may  range  in 
size  from  a personal  computer  up  to  a supercomputer.  A general  control 
center  architecture  i3  shown  in  Figure  7. 4. 6. 3. 2-1.  In  this  architecture, 
most  flight  control  functions  are  considered  to  be  local  and  are  partitioned 
into  their  own  workstations.  Communications  and  the  distribution  of 
spacecraft  data  are  global  functions  supported  by  the  LAN.  It  should  be 
noted  that  large  functions  or  processors  do  not  indicate  that  a function  is 
global  in  nature.  Uplink  collection  is  a prime  example.  All  commands  from 
the  control  center  are  collected  at  a single  workstation  that  formats  them 
into  uplink  packets.  Thus,  the  function  is  global  in  nature;  however,  a 
small  computer  can  easily  perform  the  function. 

The  LAN  is  the  "glue"  that  holds  the  architecture  together.  The  LAN  provides 
a general  communications  service  for  the  workstations.  The  workstations  can 
send  messages  containing  data,  programs,  files,  or  any  information  to  each 
other  without  the  necessity  of  going  through  a central  computer.  By  meeting 
the  protocol  standards  of  the  network,  any  type  of  device  can  be  connected 
and  can  communicate  over  the  LAN.  While  functions  that  wish  to  communicate 
must  agree  on  information  content,  the  LAN  will  provide  the  means  of 
information  exchange. 
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Figure  7.4.6.3.2-1.  General  Control  Center  Architecture 


A generic  control  center  architecture  is  produced  by  mapping  the  control 
center  systems  into  the  network  and  workstation  concept.  Figure  7. 4. 6. 3. 2-2 
shows  the  result  of  the  mapping.  The  front  end  interface  receives  the 
spacecraft  downlink  and  separates  the  voice,  video,  telemetry  and  general 
messages.  It  also  transmits  command  packets  to  the  spacecraft.  The 
telemetry  is  sent  to  workstations  via  the  TLM  net  while  commands  and  other 
general  communications  move  along  the  general  purpose  net.  Some 
workstations  monitor  and  control  spacecraft  systems  by  receiving  core 
engineering  data  and  building  commands.  Workstations  of  another  group 
receive  tracking  data  necessary  to  perform  the  trajectory  function.  A third 
workstation  collects  all  commands  and  builds  uplink  CCSDS  packets  which  are 


Figure  7.4.6.3.2-2.  Generic  Control  Center  Architecture 
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transmitted  to  the  front  end  interface.  The  facility  management 
workstations  provide  library  and  system  management  functions.  Finally,  the 
scheduler  supports  various  mission  scheduling  activities. 

The  selection  of  workstations  is  accomplished  in  much  the  same  way  as  any 
processor.  The  workstation  provides  the  following  capabilities: 

• CPU/Memory  System 

• Disk  Storage 

• Graphics  Display  Device 

• Keyboard  and  other  input  devices 

• LAN  Interfaces 

• Special  Interfaces 

Other  workstations  in  the  system  may  have  functional  requirements  that  make 
them  larger  or  smaller  with  different  configurations.  For  example,  the 
facility  manager  may  need  to  be  a mainframe  computer  in  order  to  support  the 
library  function.  While  there  is  economic  advantage  in  reducing  the  number  of 
machine  types,  the  architecture  allows  all  machines  to  be  of  different  types 
provided  that  they  can  communicate  over  the  LAN(s).  Since  functions  are 
hosted  in  a workstation  with  only  related  functions,  other  functions  may  grow 
and  change  and  even  migrate  to  a larger  workstation  without  impacting  other 
workstations  in  the  system.  The  temptation  to  force  a function  to  remain  in 
a given  processor  over  the  useful  life  of  the  function  is  reduced.  This  is 
due  to  the  reduced  cost  of  equipment  and  the  fact  that  many  small  processors 
rather  than  a single  large  mainframe  are  utilized.  This  also  allows  code  to 
remain  structured  and  straightforward  rather  than  using  special  "tricks"  to 
make  modifications  fit  into  the  existing  system.  Equipment  has  gotten 
inexpensive  while  labor  costs  have  increased  dramatically.  The  lower 
equipment  costs  allow  this  architecture  to  be  cost-  competitive. 

7. 4. 6. 3. 2.1  SSOCC  Configuration  and  Architecture 

The  configuration  for  the  SSOCC  is  shown  in  Figure  7. 4. 6. 3 .2. 1-1.  The  control 
center  is  divided  into  two  parts:  monitor  and  control,  and  mission 

scheduling . 
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Figure  7.4.6.3.2.1-1.  SSOCC  Configuration 


7. 4. 6. 3. 2. 1.1  Monitor  and  Control 


The  monitor  and  control  facility  is  divided  into  FCR  and  MPSR  areas  as 
described  in  section  7. 4. 6. 3. 1.1.  The  details  of  each  FCR  and  MPSR  are  shown 
in  Table  7 . 4 . 6 . 3 . 2 . 1 . 1-1 . It  is  important  to  note  that  these  quantities  and 
configurations  can  be  easily  changed  to  support  the  buildup  and  mature 
operations  without  changing  the  overall  architecture . The  major  functions 
performed  by  the  monitor  and  control  facility  are  as  follows: 


• Network  Communications 

• Monitor  and  Control 

• Trajectory 

• Command 

• Data  Presentation  and  Retention 

• Facility  Management 

• Joint  Operations  Support 


Table  7. 4. 6. 3. 2.1 .1-1 
SSOCC  WORKSTATION  QUANTITIES 


AREA 

SYSTEM  DIVISION 
FLIGHT  OIRECTOR 
CAP  COMM 
EVA 

CREW  SYSTEMS 
TRAJECTORY 
PAYLOADS 
FLIGHT  PLANNING 

LOGISTICS/MANIFESTING/SCHEDULING 


FCR  MPSR 

7(1)  14(2) 

1 
1 

1 1 

2 

3 6 

6 

1 3 

3 


TOTAL  14(1)  35(2) 

( ) - Oelta  for  OMV  Proximity  Operations 
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The  network  communications  system  is  composed  of  the  following  items: 

• Gateway  to  the  JSC  IMet 

• TLM  Formatter 

• General  Purpose  (GP)  Net 

• TLM  Net 

• Bridges  to  STS  Mission  Control  Center  (MCC)  Nets 

• Voice/Video  Distribution 

The  gateway  selects  the  packets  of  core  engineering  data  addressed  to 
elements  in  the  monitor  and  control  facility.  These  packets  are  divided  into 
telemetry /tracking  and  general  message  types  and  routed  to  either  the  TLM 
Formatter  or  onto  the  GP  Net.  The  TLM  Formatter  converts  the 
telemetry/tracking  parameters  into  the  common  JSC  format  for  broadcast  on  the 
TLM/TRK  Net.  The  GP  Net  provides  standard  OSI  type  network  communications 
that  are  compatible  with  the  STS  MCC.  The  TLM/TRK  Net  provides  a broadcast 
of  information  that  is  not  compatible  with  the  OSI  seven  layer  model.  It  is 
fully  compatible  with  the  MCC  counterpart,  however.  The  bridges  to  the  MCC 
nets  allow  the  SSOCC  and  MCC  to  share  information. 

The  telemetry  function  provides  the  ground  monitor  and  control  of  onboard 
systems.  Activities  include  trend  analysis  and  limit  sensing  and  other 
real-time  operations.  These  activities  are  performed  in  workstations  which 
are  manned . 

The  trajectory  workstations  provide  support  for  navigation,  guidance, 
attitude  control,  tracking  and  traffic  control.  The  workstation  capabilities 
are  similar  to  those  described  for  telemetry.  Both  the  FCR  and  MPSRs  provide 


The  command  function  is  divided  into  two  parts.  Some  controller  positions 
that  ’nonitor  telemetry  and  tracking  data  are  allowed  to  command  various 
onboard  systems.  Through  the  use  of  both  conventional  and  expert  system 
consultants,  a high  degree  of  automation  is  achieved.  This  allows  a 
workstation  to  generate  command  sequences  and  predict  the  effects  of  the 
command  sequences.  These  predictions  can  include  an  assessment  of  the 
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impacts  of  a command  sequence  with  respect  to  safety,  effect i v i ty , conflicts 
with  scheduled  activities,  etc,  The  commands  are  built  at  these  locations 
and  sent  to  the  uplink  collection  processor.  This  processor  represents  the 
second  part  of  the  command  function.  This  processor  validates  the  command 
formats  and  builds  them  into  CCSDS  packets  for  uplink  to  the  Space  Station. 

Data  presentation  and  retention  is  accomplished  by  the  workstations  in 
support  of  mission  support  personnel.  Information  is  displayed  on  color  CRTs 
as  well  as  printer  or  plotter  type  devices.  A typical  workstation  of  this 
type  is  shown  in  figure  7 . 4 . 6 . 3 . 2 . 1 . 1-1 . Short-term  data  retention  is  done  by 
these  workstations  in  order  to  recall  and  process  selected  information  for  a 
time  of  at  least  two  hours.  Any  information  older  than  that  stored  in  the 
workstation  must  be  requested  from  the  EDC.  Local  retention  can  be  increased 
by  increasing  the  amount  of  disk  storage  of  the  workstation.  Typical 
workstation  capabilities  are  shown  in  table  7 . 4 . 6 . 3 . 2 . 1 . 1-2 . A functional 
block  diagram  is  shown  in  figure  7 . 4 . 6 . 3 . 2 . 1 . 1-2 . 


Table  7.4.6.3.2.1.1-2.  Workstation  Capabilities 


• Multiple  32-bit  CPUs 

• Floppy  Disk 

• 400-Mbyte  Hard  Disk 

• Color  Graphics 

• Floating  Point  Processor 

• Command/Visual  Graphics  Control 

• Printer-Plotter  Access 

• Furniture 

• LAN  Interfaces 


The  facility  manager  provides  data  management  for  the  workstations.  It 
monitors  and  schedules  the  workstations  and  related  equipment.  This  system 
uses  a mainframe  computer  which  collects  inputs  from  workstations  and 
provides  the  library  services.  These  inputs  are  used  by  an  AI  (LISP) 
processor  that  produces  facility  schedules  and  supports  the  management  of 
facility  resources . 

Joint  Operations  Support  is  provided  by  a group  of  workstations  similar  to 
those  used  for  telemetry  processing.  These  workstations  collect  various  core 
engineering  and  computed  data  and  transmit  the  information  to  other  Control 
Centers.  These  workstations  can  be  controlled  by  users  at  the  other 
Centers.  As  a result,  the  man-machine  interface  equipment  is  not  as 
sophisticated  as  those  for  telemetry  processing. 

The  quantities  and  descriptions  of  the  support  rooms  are  shown  below.  These 
estimates  are  based  on  studies  done  by  the  Mission  Operations  Directorate  at 
JSC. 


1 FCR  - Primary  flight  support 
3 MPSR  - Flight  support 

3 MPSR  - Planning,  training  or  other  activities 

The  MPSRs  for  planning  are  not  included  in  the  workstation  counts  in  Table 
7. 4. 6, 3. 2. 1.1-1. 

The  data  formats  of  the  LANs  in  the  SSOCC  fall  into  two  groups  based  on  the 
function  of  each  LAN.  The  general  purpose  net  is  an  implementation  of  the  ISO 
seven  layer  model  used  in  the  STS  MCC.  The  telemetry  and  tracking  LAN 

C w <p 
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conforms  to  the  JSC  implementation  in  the  STS  MCC.  The  general  message  format 
is  shown  below. 

HEADER  General  block  descriptor 

DESCRIPTORS  Parameter  number,  type,  location,  length 

DATA  Actual  parameters 

7 . 4. 6 . 3 . 2. 1 . 2 Mission  Scheduling. 

The  Mission  Scheduling  System  is  composed  of  two  types  of  computers.  The 
service  interface  processor  collects  planning  and  scheduling  information  as 
well  as  necessary  resource  status  and  schedule  requests.  This  information 
comes  from  various  control  centers  and  payload  users  as  well  as  the  onboard 
system.  Various  schedules  are  distributed  to  these  same  locations.  Since  this 
is  mostly  an  information  system,  a large  mainframe  computer  with  a 
significant  amount  of  disk  storage  is  a reasonable  choice.  An  IBM  3083 
represents  the  class  of  machine  needed.  A group  of  LISP  processors  are 
attached  to  the  mainframe  to  produce  schedules.  Machines  of  the  SYMBOLICS 
3670  class  are  representitive  examples.  On  the  order  of  six  of  these  machines 
are  required. 

7. 4. 6. 3. 2. 2 COPCC/POPCC  Configuration  and  Architecture 

The  configuration  for  the  COPCC/POPCC  is  shown  in  figure  7 . 4 . 6 . 3 . 2 . 2-1 . This 
is  similar  to  the  architecture  for  the  SSOCC  described  in  section 
7. 4. 6. 3. 2.1.  The  two  major  functions  of  mission  scheduling  and  monitor  and 
control  are  identical  in  nature  to  the  SSOCC. 

7. 4. 6. 3. 2. 2.1  Monitor  and  Control 

The  monitor  and  control  of  platforms  is  accomplished  through  the  use  of 
platform  control  rooms.  Each  platform  control  room  controls  a single  platform. 
This  allows  for  easy  expansion  as  the  number  of  platforms  increases.  The 
functions  of  the  monitor  and  control  facility  are  as  follows: 


Network  Communications 
Monitor  and  Control 
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Figure  7.4.6.3.2.2-1.  COPCC/POPCC  Configuration 


• Trajectory 

• Command 

• Data  Presentation  and  Retention 

• Facility  Management. 

The  network  communications  system  is  composed  of  the  following: 

• Gateway  to  the  GSFC  nets 

• TLM  Formatter 

• TLM  IMet 

• GP  Net 

• Voice/Video  Distribution 

The  gateway  separates  the  telemetry/tracking  data  from  the  general  type 
messages.  The  TLM  Formatter  converts  the  telemetry/tracking  data  into  a 
format  of  self  identifying  parameters  for  broadcast.  The  TLM/TRK  Wet  provides 
the  physical  means  to  deliver  these  parameters  to  the  workstations.  The 
gateway  uses  the  GP  Net  to  deliver  the  general  type  of  messages.  The  message 
protocol  conforms  to  the  ISO  seven  layer  model  for  the  GP  net.  The  TLM/TRK 
Net  uses  the  same  broadcast  protocol  described  by  the  SSOCC. 


The  telemetry  processing  provides  ground  monitor  and  control  support  of  the 
platform  core  systems.  Workstations  similar  to  those  described  in  section 
7. 4. 6. 3. 2. 1.1  are  needed  to  support  these  activities.  The  workstations  are 
capable  of  storing  at  least  two  hours  of  selected  parameters  for  review  and 
analysis.  The  display  of  information  and  graphics  support  the  human 
interface  necessary  for  decision-making  and  command  activity. 

The  trajectory  functions  are  accomplished  through  the  use  of  workstations  and 
the  Flight  Dynamics  Facility  (FDF).  The  same  type  of  workstations  support 
trajectory  as  are  used  for  monitor  and  control.  The  FDF  provides 
computational  support  for  such  activities  as  orbit  and  attitude  calculations. 
The  trajectory  activities  include  support  for  navigation,  guidance,  attitude 
control,  tracking  and  traffic  control. 
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Command  processing  is  similar  in  nature  to  that  performed  within  the  SSOCC 
and  includes  verification,  validation,  safing,  uplink  formatting,  etc.; 
however,  authorization  may  be  limited  to  a single  workstation. 

The  data  presentation  and  retention  are  accomplished  through  the  use  of 
workstations.  Section  7. 4 . 6 . 3 . 2 . 1 . 1 also  contains  a description  and  figures 
depicting  a typical  workstation  used  for  this  activity.  Long-term  data 
retention  is  done  in  the  Platform  EDC  while  short— term  retention  is 
accomplished  by  the  workstations. 

Facility  management  provides  library  services  as  well  as  equipment  monitoring 
and  scheduling  for  all  equipment  in  the  COPCC/POPCC.  A mainframe  computer 
manages  the  collection  and  distribution  of  information  while  LISP  processors 
produce  the  actual  schedules  and  provide  conflict  resolution  and  fault 
analysis  and  recovery.  The  library  services  provide  global  storage  of  files 
for  the  workstations. 


The  number  of  control  rooms  for  platforms  is  as  follows: 

1 COP 

2 POP 

1 Training  and  development. 

Six  workstations  are  estimated  for  support  of  each  platform. 

The  data  formats  for  the  LANs  are  the  same  as  those  described  in  section 

7. 4. 6. 3. 2. 1.1  for  the  SSOCC. 

7 . 4 . 6 . 3 . 2 . 2 . 2 Mission  Scheduling 

The  Mission  Planning  System  performs  the  mission  scheduling  for  all 
platforms.  The  same  basic  configuration  that  supports  Space  Station  Mission 
Scheduling  also  supports  Platform  Mission  Scheduling.  The  number  of  AI 
(LISP)  processors  is  reduced  from  six  to  four,  however. 


7-88 


7.4.7  ENGINEERING  DATA  CENTERS 


The  Engineering  Data  Centers  provide  archival  storage  of  core  engineering 
data.  The  data  is  kept  within  the  archive  for  a minimum  of  two  years  with 
longer-term  retention  at  the  SSP's  discretion  or  as  arranged  through 
negotiations  with  the  customer.  Per  the  design,  there  are  two  Engineering 
Data  Centers  — one  for  the  storage  of  Space  Station  core  data  and  one  for 
the  storage  of  platform  data.  The  Space  Station  EDC  is  located  at  JSC,  and 
the  Platform  EDC  is  located  at  GSFC.  The  capability  exists  via  the  Mission 
Scheduling  System,  in  conjunction  with  the  GSC's  network  management 
function,  to  route  data  destined  for  one  of  the  EDC's  to  the  other  for 
temporary  storage  in  the  event  of  the  primary  EDC's  failure. 

7.4.7. 1 Interface  Description 

The  functional  interfaces  of  the  EDC  are  listed  in  Table  7.4.7. 1-  1.  Due  to 
their  near  real-time  nature,  the  functional  interfaces  to  the  Space  Element 
and  Control  Center  are  managed  at  a higher  priority  than  are  the 
non-real-time  interfaces  to  the  other  elements. 

7.4. 7. 2 Function  Description 

The  following  subsections  discuss  the  EDC  systems  that  perform  the  functions 
identified  in  Table  7, 2. 3-1. 

7. 4. 7. 2.1  Communications 

The  Communications  system  provides  the  interface  to  the  wide  area  and  local 
area  networks  connecting  the  EDC  to  the  other  SSPE's  and  to  the  intra-EDC 
data  distribution  networks.  The  system  provides: 

a.  External  Interface  Management 

• Support  communication  link  monitoring 

• Provide  transmission  error  detection 

• Support  protocols  requiring  acknowledgements  and  retransmissions 

• Provide  performance  monitoring  data  to  GSC 
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Table  7, 4. 7. 1-1 


EDC  Functional  Interfaces  to  Ground  Elements 
Element  Interface  Traffic  Purpose 


DHC  Core  Downlink 

(as  gateway 

to  Space  Queries/Responses 

Element) 


Archival  storage 
Archival  retrieval 


Control  Center  Core  Uplink, 
Computed  Data 


Archival  storage 


Queries/Response  Archival  retrieval 

Schedules/Status  Ground  resource  mgmt. 


POCC's  Queries/Responses  Archival  retrieval 

LZPF’s 

RDC's 

Customers 


Alternate  Data  Records  Fault  recovery 

EDC 


Central  Catalog  Updates 

Catalog 

Service 


Maintenance  of  Central 
Catalog 


GSC 


Resource  Usage  Customer  billing 

Records 
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b.  Data  Processing 

• Perform  required  preprocessing  (e.g.  core  data  level  0 
processing  and  data  extraction) 

• Route  data  to  storage/retrieval  systems 

7. 4. 7. 2. 2 Archival  Storage 

The  EDC's  Archival  Storage  system  provides  for  the  entry  of  core  data  into 
archives.  The  services  provided  are: 

a.  Two  year  storage  (nominal;  longer  if  negotiated)  of  audio,  video,  and 
digital  data 

• Provide  data  compression  (if  necessary) 

b.  Support  the  central  cataloging  functions  of: 

• Inventoring  of  archive  data 

• Information  on  where  data  is  located 

• How  to  get  it 

• Options  on  format  and  transmission  media 

7. 4. 7. 2. 3 Retrieval 

The  EDC's  Retrieval  system  supports  the  search  for  and  recovery  of  archival 
core  data  for  transmission  to  SSPE's.  Services  include: 

a.  Process  stored  data  request  from  SSPE's 

b.  Provide  access  control  to  stored  data 

c.  Perform  requested  analyses  of  engineering  data 
• Report  generation 

d.  Support  the  transfer  of  data  in  standard  format  data  units  (SFDU)) 

e.  Maintain  usage  records  for  customer  billing 

7. 4. 7. 2. 4 Facility  Management/Scheduling 

These  functions  manage  the  configuration  of  the  EDC  resources  in  order  to 
minimize  the  impact  of  equipment  failure  and  to  ensure  that  the  proper 
configuration  is  provided  for  scheduled  support.  The  EDC's  scheduling 
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function  interacts  with  its  respective  Mission  Scheduling  System,  providing 
status  and  accepting  and  executing  schedules.  Per  a schedule  request,  these 
facility  functions  configure  the  EDC  to  support  the  entry  and  temporary 
storage  of  the  alternate  EDC's  data. 


7. 4. 7. 3 Design  Approach 

The  design  approach  for  the  Engineering  Data  Center- addresses  common  design 
drivers  and  architectures . Then  the  unique  design  drivers  and  architectures 
are  addressed  for  each  EDC.  Since  the  basic  functions  are  the  same,  most  of 
the  design  drivers  and  architecture  are  common. 

7. 4. 7. 3.1  Generic  Design  Drivers 

The  generic  design  drivers  for  the  EDC's  are  very  similar  to  those  of  the 
control  centers.  These  design  drivers  are  discussed  below. 

• FLEXIBILITY  — This  quality  allows  the  EDC  to  meet  changing  needs  in  a 
timely  and  cost  effective  manner. 

• TECHNOLOGY  INSERTION  - As  improvements  are  made  in  technology,  they 
should  be  easy  to  incorporate. 

• GROWTH  - As  demands  and  requirements  increase,  the  system  must  allow 
additional  resources  to  be  added  easily. 

• LIFE  CYCLE  COST  — The  design  should  utilize  concepts  that  reduce 
operating  costs  as  well  as  controlling  initial  purchase  price. 

• RELIABILITY  — The  EDC's  should  be  designed  in  such  a way  that  one  may 
at  least  provide  data  capture  capability  in  the  event  that  the  other 
EDC  is  down. 

• AUTOMATION  - In  order  to  reduce  staffing  and  to  improve  response 
time,  the  retrieval  of  data  from  the  archives  should  be  as  automated 
as  possible. 
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• COMMERCIAL  OFF  THE  SHELF  (COTS)  - The  use  of  commercially  produced 
equipment  in  place  of  custom  built  equipment  is  highly  desirable. 

• REUSABILITY  - The  design  should  utilize  hardware  and  software 
developed  through  other  projects  when  possible. 

7. 4. 7. 3. 1.1  SS  EDC 

The  SS  EDC  has  a stable  input  data  rate  and  a high  retrieval  activity  as 
unique  design  drivers. 

7. 4. 7. 3. 1.2  Platform  EDC 

The  Platform  EDC  data  rates  and  storage  requirements  change  as  a function  of 
the  number  of  platforms . 

7. 4. 7. 3. 2 Generic  Configuration  and  Architecture 

The  generic  architecture  is  shown  in  figure  7. 4. 7. 3. 2-1.  The  primary 
components  of  the  EDC  are  listed  below. 

• Communications 

• Storage  processing 

• Data  storage 

• Retrieval  processing/analysis 

• Service  interface  processing 

The  communications  system  provides  a gateway  to  select  and  route  the  data  and 
messages.  The  Data  Net  provides  for  the  transfer  of  core  type  information 
like  telemetry  and  tracking  data.  The  General  Purpose  Net  carries  the  regular 
traffic  associated  with  requests  and  control.  Storage  processing  is 
responsible  for  data  capture  and  any  formatting  associated  with  storing  and 
organizing  the  data.  The  data  store  is  the  retention  media.  The 
retrieval/analy sis  handles  queries  and  formats  the  results  as  well  as  sending 
the  results  to  the  requestor.  The  service  interface  processor  manages  the 
system  and  performs  the  accounting  associated  with  the  services. 
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Figure  7.4.7.3.2-1.  Engineering  Data  Center 


7. 4. 7. 3. 2.1  Space  Station  EDC  Configuration  and  Architecture 

The  storage  and  the  retrieval  processors  are  of  the  mainframe  class.  IBM  308X 
computers  are  representitive  examples.  The  service  interface  processor  is  of 
the  same  type  as  well.  The  data  store  consists  of  magnetic  disk  that  holds 
four  to  six  hours  of  data.  This  is  treated  as  a circular  queue.  This  allows 
data  to  be  replaced  by  that  of  better  quality  should  it  be  available.  Once 
the  data  is  stable,  it  is  transferred  to  optical  disk  for  archival  storage.  A 
system  like  the  RCA  "Optical  Disk  Jukebox"  identified  in  the  Task  3 report  is 
representitive  of  the  technology  required.  By  using  a library  manager,  older 
data  can  be  stored  offline  and  loaded  on  demand.  The  system  management  and 
accounting  files  are  magnetic  disk.  The  amount  of  storage  required  is  shown 
in  the  following  table. 

OPTICAL  4000  Gbytes  (core  engineering  data  without  data  compression) 

MAGNETIC  10  Gbytes. 

It  should  be  noted  that  the  performance  of  the  storage  processor  is  a . 
function  of  the  amount  of  reformatting  necessary  to  place  the  data  into  the 
database  system.  If  the  downlink  data  is  organized  in  blocks  that  are  the 
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same  as  database  records,  the  processing  is  greatly  reduced.  Thus, 
coordination  with  the  onboard  system  is  very  important.  The  cost  of  the 
storage  processor  could  be  reduced  as  a smaller  machine  could  be  used.  The 
use  of  a database  machine  to  support  queries  and  storage  represents  a 
possible  cost  reduction  by  reducing  the  loading  on  both  storage  and  retrieva 
processors . 

7. 4. 7. 3. 2. 2 Platform  EDC  Configuration  and  Architecture 

The  same  configuration  that  supports  the  Space  Station  EDC  can  support  the 
Platform  EDC.  As  the  number  of  platforms  increase,  additional  processors  and 
storage  will  need  to  be  added. 

7.4.8  Operational  Control  Network  (OCN) 

An  essential  component  of  the  design  is  the  Operational  Control  Network  which 
ties  together  all  system  components,  providing  facilities  for  internal 
coordination  of  system  functions,  downloading  of  configuration  controlled 
software  and  tables,  remote  fault  diagnosis,  and  access  to  network  components 
by  internal  and  external  users.  The  Operational  Control  Network  is 
functionally  separate  from  the  network  associated  with  the  Software  Support 
Environment/Software  Development  Environment  (SSE/SDE),  but  supports  gateway 
functions  for  transfer  of  approved  software  configurations.  Although  the 
functionality  of  the  OCN  is  somewhat  different  than  the  SSE,  the  design 
anticipates  that  much  of  the  associated  software  and  network  interface 
components  will  be  identical.  In  the  design  the  OCN  is  layered  on  the  same 
packet  network  which  supports  low-rate  data  transmission  and  is  supported 
through  ISO-compatible  network  services  associated  with  Layers  4 through  7. 


7.4.8. 1 Functional  Interface  Description 

The  Operational  Control  Network  interfaces  with  all  major  SSDS  ground 
components  either  directly  through  the  packet  network  or  indirectly  through 
LAN  connections  to  packet  network  servers.  ISO-compatible  services  for  remote 
terminal  access,  file  transfer,  and  remote  peripheral  access  are  provided  for 
all  the  general  purpose  processors  in  the  SSDS  configuration.  The  network  is 
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fully  interconnected  with  network  access  security  provided  at  all  external 
gateway  s . 

7. 4. 8. 2 Function  Description 

The  OCN  is  a backbone  network  which  provides  essential  services  for 
coordinating  the  operations  of  the  ground  elements  of  the  SSDS.  It  will 
support  the  following  functions: 

Software  Downloading  — to  provide  for  transfer  of  new  software  releases  to 
target  processors,  and  to  support  startup  of  software  on  remote  nodes, 
particularly  microprocessors  which  do  not  support  local  storage  of  software 
images . 

Remote  Terminal  Access  — to  allow  remote  logon  and  system  access  by  internal 
and  external  users  through  packet  network  facilities. 

External  Logon  — to  verify  the  identity  and  log  access  to  network  elements  by 
external  users  entering  through  tail  circuits  and  gateways.  The  OCN  does  not 
control  access  to  individual  components  (e.g.  DHC  or  LZPF)  but  does  control 
network  access. 

Customer  Interface  — to  provide  menus  of  services  and  connect  users  to  these 
services  (e.g.  in  a manner  like  the  Telenet  logon  menus). 

Network  Messaging  and  Reporting  — to  provide  standard  services  which  support 
scheduling  of  network  resources,  status  and  event  reporting,  and  accounting 
messages,  particularly  through  communication  with  the  GSC. 


Remote  Diagnosis  — to  support  the  location  and  diagnosis  of  SSDS  component 
failures . 

Remote  Device  Access  — to  support  network  access  of  storage  and  output 
devices  for  remote  data  base  access,  reporting,  and  logging. 
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Network  Cold  Start,  Restart,  and  Switchover  — to  accomplish  essential 
coordination  functions  during  network  startup  and  switchovers  associated  with 
network  element  maintenance  and  failure  recovery. 

7. 4. 8. 3 Design  Approach 

The  design  approach  assumes  that  the  underlying  Layers  1 to  3 of  the  ISO  model 
are  provided  by  the  low— rate  services  of  the  data  distribution  network  and  all 
ground  elements  of  the  SSDS  have  local  gateways.  Only  the  additional  elements 
required  to  provide  the  above  functionality  are  described.  Issues  of  network 
control  center  design  or  network  structure,  other  than  those  which  are 
internal  to  the  SSDS  or  are  customer  interfaces,  are  not  considered. 

7. 4. 8. 3.1  Physical  Structure 

Each  configurable  element  of  the  design  is  connected  to  the  OCN.  Connection 
may  be  directly  to  the  packet  network,  indirectly  through  a LAN  and  packet 
network  server,  or  through  a host  processor  (for  certain  special  purpose 
processors  such  as  the  high  bandwidth  I/O  processors  at  the  LZPF) . Backup 
connections  also  exist  for  certain  critical  activities;  for  example,  the 
Ground  Services  Center  is  equipped  with  alternate  dialup  links  to  all  SSDS 
ground  facilities  for  communications  during  packet  network  gateway  failures. 
However,  all  routine  control  communication  is  normally  routed  through  the 
packet  network.  The  conceptual  model  for  the  physical  system  interconnection 
is  similar  to  the  structure  currently  provided  by  DECnet,  which  provides  for 
multiple  high  and  low  bandwidth  LAN's  with  reconf igurable  interfaces  and 
internet  gateways  for  creating  subLAN's  and  connecting  them  to  external  wide 
area  data  networks. 


7. 4. 8. 3. 2 Gateway  Functions 

OCN  gateways  are  provided  at  all  SSDS  facilities  and  at  tail  circuit 
locations.  The  structure  of  the  gateways  is  not  an  SSDS  design  element,  but 
has  substantial  impact  on  SSDS  design  and  customer  interface.  Customer 
Interface  Elements  (CIE)  located  at  tail  circuit  gateways  provide  a 
menu-oriented  choice  of  network  services  and  support  easy  access  to  the 
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specialized  capabilities  of  SSDS  facilities  (e.g.  command  uplink  at  the  DHC, 
GSC  communication,  LZPF  real-time  or  store  and  forward  services).  The  gateways 
also  serve  to  control  access  to  SSDS  nodes  preventing 

entry  by  "hackers"  and  logging  all  sessions  established  by  external  users. 

7. 4. 8. 3. 3 Network  Services 

OCN  services  at  the  Application  layer  were  described  in  Section  7. 4. 8. 2.  The 
design  uses  a set  of  standard  network  services  similar  to  the  high  level 
services  provided  by  the  NBS  standards,  DECnet,  or  SNA.  The  various 
SSDS-specif ic  communications  which  will  pass  over  the  OCN  were  described  in 
earlier  sections  on  the  individual  ground  system  elements. 

7. 4. 8. 3. 4 Network  Management 

The  GSC  provides  network  management  services  relevant  the  the  SSDS  elements. 
The  GSC  coordinates  SSDS  element  startup  and  loads  authorization  and 
configuration  tables  throughout  the  SSDS  utilizing  the  standard  Applications 
Layer  services  provided  by  the  OCN.  Status,  event,  accounting,  and  data 
quality  are  reported  directly  to  the  GSC.  A customer  experiencing  problems 
with  data  quality,  data  access,  or  any  SSDS  service  uses  the  GSC  as  a single 
point  of  contact  for  problem  reporting.  In  the  event  of  a reported  SSDS 
failure  the  GSC  uses  OCN  facilities  to  localize  the  problem  and  coordinate 
problem  solution  working  with  appropriate  data  distribution  network,  NCC,  or 
local  SSDS  facilities  to  resolve  the  problem  and/or  switch  over  to  system 
backups . 

Although  it  may  be  collocated  with  the  packet  network  control  center,  the  GSC 
does  not  provide  packet  network  security  services  or  fault  diagnosis.  The  GSC 
does,  however,  cooperate  with  network  elements  in  locating  and  diagnosing 
faults  at  the  communications  gateways  and  other  SSDS  boundary  elements. 


7.5  Summary 

In  the  process  of  performing  the  SSDS  A/A  Study  several  key  issues, 
assumptions,  and  uncertainties  have  been  identified  which  impacted  the  choice 
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of  a ground  system  architecture,  and  which  should  be  analyzed  in  greater 
detail  in  Phase  B.  Decisions  on  these  areas  will  have  a significant  impact  on 
the  cost  and  operations  of  the  end-to-end  SSDS. 

7.5.1  Level  0 Delivery  Requirements 

The  definition  of  the  "delay  requirement"  in  the  Langley  database  has 
important  impacts.  Does  a "zero  delay"  requirement  include  Level  0 processing? 
Is  it  required  to  deliver  the  level  0 data  for  high  rate  missions  within  24 
hours,  for  a particular  data  set;  or  are  longer  delays  allowed?  In  the  SSDS 
Study,  the  maximum  allowed  delay  is  24  hours.  Longer  delays,  especially  for 
high  rate  data,  might  allow  non-electronic  distribution  of  data,  e.g, 
distribution  of  optical  disks. 

7.5.2  Real  Time  & Quick  Look  Data  Requirements 

An  SSDS  requirement  is  that  the  SSDS  must  be  capable  of  transmitting  the  raw 
or  quick  look  data  in  real  time  to  POCCs  and  customers.  This  requirement 
favors  a distributed  level  0 processing  architecture,  since  it  implies  that 
communications  are  needed  to  the  POCCs  and  RDCs  anyway  to  meet  the  real  time 
requirement . 

7.5.3  Definition  Of  RDC 

While  assumptions  have  been  made  as  to  the  number,  locations,  and 
responsibilities  of  Regional  Data  Centers,  in  reality  these  issues  are 
uncertain  and  are  in  fact  significantly  affected  by  programmatic  decisions. 
Further  programmatic  refinement  of  the  assumptions  regarding  RDC's  will  be 
important  in  Phase  8. 


For  example,  in  this  study  it  has  been  assumed  that  the  SSIS  capabilities  will 
be  established  to  provide  higher  level  data  processing  at  the  Regional  Data 
Centers.  A current  example  of  this  support  i3  the  Upper  Atmospheric  Research 
Program  (UARS)  Central  Data  Handling  Facility.  The  impact  of  this  assumption 
is  that,  regardless  of  where  the  Level  0 processing  is  done,  the  data  must  be 


7-99 


sent  to  a few  key  locations.  In  addition,  the  advantages  of  co-location  of 
Level  0 and  upper  Level  processing  for  high  rate  missions  — for  example,  to 
simplify  retrieval  from  the  seven  day  Level  0 archive  — must  be  explored,  as 
has  been  done  in  the  Network  Topology  Trade  Study. 

Another  contrasting  view  is  that  upper  level  processing  support  may  migrate 
to  users  for  some  missions.  For  example,  support  for  low  rate  missions  might 
consist  of  archiving  for  data  products  only.  An  example  of  such  support  is  the 
National  Space  Science  Data  Center.  Data  would  be  sent  from  the  Level  0 
processing  facility  directly  to  users  via  the  data  distribution  network.  The 
Gamma  Ray  Observatory  (GRO)  program  takes  this  approach. 

Another  question  is  whether  upper  level  processing  must  do,  and  have  the 
capability  to  do  the  necessary  processing  to  verify  that  they  have  a usable 
dataset,  within  7 days  since  the  data  is  discarded  by  the  Level  0 SSDS  site  at 
this  time.  IF  the  Upper  Level  processing  sites  do  not  have  substantial 
processing  capability,  then  they  may  not  be  able  to  verify  that  the  data  is 
correct  within  the  7 day  period. 

Resource  sharing  between  Level  0 and  upper  level  processing  is  another  issue, 
and  it  appears  to  be  more  significant  for  high  rate  missions.  Resources  to  be 
shared  include  facilities  and  people,  and  it  may  be  possible  to  share  the 
processing,  working  storage,  and  archival  resources  between  the  level  0 and 
the  upper  level  processing.  For  example,  it  would  appear  that  the  high  rate 
missions  would  require  high  throughput  processors  in  order  to  produce  data 
products  in  a reasonable  time  period.  Another  example  is  sharing  between  7-day 
and  long-term  level  0 archiving.  Such  sharing  is  speculative  since  the 
reliability  and  processing  requirements  are  different,  but  the  cost  impact  of 
the  high  rate  missions  appears  to  warrent  it  being  investigated. 


7.5.4  Uncertainty  of  requirements 

While  the  Langley  Mission  requirements  provided  valuable  input,  these 
requirements  have  uncertainties,  and  these  increase  over  time.  Missions  will 
be  added  and  subtracted  over  the  lifetime  of  the  Space  Station  and  the 
alternatives  should  be  compared  in  terms  of  their  ability  to  accommodate  these 
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changes.  Flexible  architectures  are  favored,  and  this  is  one  reason  the  hybrid 
approach  to  Level  0 processing  was  chosen. 

Definition  of  required  "standard  services"  are  also  important.  This  study  has 
taken  the  view  that  a standard  service  is  one  that  must  be  provided  to  all 
customers,  as  opposed  to  the  majority  of  customers. 

7.5.5  Uncertainty  of  Ground  System  Traffic 

The  Langley  Mission  Requirements  do  not  specify  elements  of  key  concern  to  the 
ground  system,  such  as  the  ground  destination  for  the  data.  The  ground 
destinations  for  the  mission  data  must  be  defined  to  determine  the  locations, 
data  traffic  to,  and  processing  requirements  of  each  Level  Zero  Processing 
Facility.  An  additional  SSIS  issue  is  electronic  delivery  to  customer  sites. 

Do  these  sites  cluster  in  key  geographic  regions,  or  are  customers  widely 
distributed? 

In  addition  to  defining  user  requirements  in  these  areas,  the  issue  for  Phase 
B is  again  flexibility  — for  example,  to  support  changes  in  customer 
locations . 

7.5.6  Sensitivity  to  Key  Missions  & Characteristics 

A large  number  (about  60—75%)  of  the  missions  operate  at  fairly  low  rates 
(less  than  0.1  Mbps)  while  a few  key  missions  operate  at  extremely  high  rates 
(up  to  300  Mbps).  The  issue  for  Phase  B is  which  alternative  both  meets  the 
mission  requirements  of  all  the  missions,  but  also  isolates  the  architectural 
impacts  of  changes  in  this  mission  mix  and  in  the  data  from  those  missions. 


For  example,  in  this  study  it  was  assumed  that  all  data  would  be  packetized, 
including  that  from  the  very  high  rate  missions.  Level  0 processing  for  packet 
data  i3  clearly  a standard  service. 

However,  concern  has  been  expressed  as  to  the  ability  of  high  rate  payloads  to 
perform  packetization,  or  if  packetization  is  used,  whether  the  packet  format 
would  be  identical  to  that  of  low  rate  missions.  It  may  be  very  difficult  to 
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perform  Level  0 processing  as  a generalized  standard  service  unless  the 
formats  are  identical.  If  this  assumption  is  considered  questionable  or 
risky,  there  will  be  impacts  on  the  choice  of  a Level  0 processing 
architecture . 

The  risk  of  a centralized  Level  0 architecture  approach  would  appear  to  depend 
in  part  on  a)  all  data  being  in  packets  of  identical  format,  or;  b)  if  the 
formats  are  not  identical,  being  able  to  build  an  advanced  telemetry  processor 
which  can  handle  an  arbitrary  format.  The  feasibility  of  both  of  these  issues 
warrants  further  attention  in  Phase  8. 

The  hybrid  approach  has  less  risk  since  all  the  low  rate  missions  are  served 
with  a centralized  service  where  there  is  little  concern  as  to  the  ability  to 
packetize.  The  resources  needed  for  the  high  rate  missions  can  be  phased  in  or 
out,  and  designed  depending  upon  the  requirements  of  the  high  rate  missions 
and  the  technology  then  available. 

7.5.7  Impacts  And  Uncertainties  Of  Communications 

The  Network  Topology  Trade  Study  made  parametric  assumptions  with  respect  to 
communications  costs,  for  completeness  in  cost  analysis,  but  communications 
has  only  been  addressed  in  terms  of  feasibility,  and  not  advisability,  of  the 
technologies.  This  is  due  to  the  fact  that  the  data  distribution  network  was 
viewed  as  an  SSIS  institutional  resource.  In  reality,  both  communications  and 
processing  should  be  examined  and  designed  together,  and  Phase  B studies 
should  examine  both  technical  and  cost  tradeoffs  between  them. 


For  example,  a distributed  Level  0 processing  architecture  might  depend  on 
being  able  to  broadcast  the  full  downlink  to  all  sites.  This  would  depend  on 
using  KA  band  technology,  which  may  or  may  not  be  feasible  due  to  rain 
attenuation.  That  is,  any  given  broadcast  site  may  be  out  due  to  rain, 
resulting  in  increased  site  outage,  duplicate  ground  stations  (site 
diversity),  and/or  additional  re-transmission  requirements  all  of  which  should 
be  studied. 
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In  addition  to  the  Level  0 architecture,  the  rest  of  the  ground  system  will  be 
distributed  and  in  such  an  environment  processing  (Nodes)  and  communications 
(links  between  the  nodes  - especially  network  (ISO  layer  3 functions)  — 
become  more  closely  interdependent.  The  successful  implementation  of  a 
distributed  processing  network  could  well  depend  on  utilizing  a sophisticated 
ISO  communications  architecture,  including  as  packet  switching,  and  could  be 
viewed  as  migrating  what  are  currently  thought  of  as  processing  functions  to 
the  communications  subsystem. 

Problems  also  arise  in  estimating  costs.  Deregulation  could  have  an 
unpredictable  impact  on  communcations  costs,  affecting  decisions  as  to  the 
number  and  locations  of  processing  centers  (RDCs). 

7.5.8  Optical  Disk  Technology 

The  overall  cost  of  the  ground  system  will  be  greatly  impacted  by  the  state  of 
the  art  of  optical  disk  technology.  This  not  only  includes  the  cost  and 
storage  size  of  the  disk,  but  also  the  use  of  read— write  technologies  which 
support  increasing  numbers  of  writes.  The  Network  Topology  Trade  Study  showed 
that  advances  supporting  100  writes  would  result  in  significant  savings. 
Magneto-optic  technologies  hold  promise  of  millions  of  writes)  greatly 
reducing  the  overall  system  cost. 

7.5.9  Common  Scheduling  Statusing,  and  Database  Interfaces 

Key  subsystems  in  the  ground  system  must  utilize  standard  interfaces  if  they 
are  to  inter-operate . Since  scheduling  is  distributed  between  the  Control 
Centers  and  the  GSC,  at  different  locations,  rapid  re-scheduling  to  support 
users  requires  electronic  communication  between  the  various  scheduling 
systems.  This  will  require  application  level  protocols  between  the  systems. 
Monitoring  of  common  resources  will  also  be  facilitated  by  the  use  of 
standardized  status  messages. 

The  various  databases  distributed  among  the  ground  elements  will  need  to 
intercommunicate  easily  and  with  users.  The  use  of  common  external  interfaces 
which  inclde  interfaces  to  the  central  catalog  service  and  common  query 
languages  will  facilitate  this  interaction. 
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7.5.10  Key  Onboard  Sensitivities 


Key  onboard  decisions  which  impact  the  ground  architecture  which  warrant 
further  study  in  Phase  B are: 

7.5.10.1  Use  Of  Virtual  Channels 

In  this  study  we  have  found  that  virtual  channels  can  greatly  simplify  the 
ground  segment  design,  and  we  have  identified  a number  of  key  uses,  as  listed 
in  Section  7.2.  The  wise  use  of  virtual  channels  is  critical  for  phase  B. 
Additional  virtual  channels  over  that  allowed  by  current  standards  may  be 
needed . 

For  example,  in  the  initial  (strawman)  onboard  SSDS  design,  all  payload 
science  data  was  packetized  and  merged  into  one  100/300  Mbps  stream.  The 
manner  in  which  playback  data  was  to  be  identified  was  not  determined,  but 
this  has  a major  impact  on  the  ground  system  design.  An  important  finding  is 
that  virtual  channels  be  used  for  this  purpose: 

• two  virtual  channels  should  be  devoted  to  each  of  the  high  rate 
payloads,  one  for  real  time,  and  one  for  playback  data 

• the  low  rate  data  can  be  packet  multiplexed  onto  one  virtual  channel 
for  real  time  and  one  virtual  channel  for  playback 

• the  virtual  channels  are  maintained  all  the  way  to  the  site(s)  of 
level  0 processing 

The  Level  0 architecture  could  be  impacted  if  these  assumptions  are  changed 
and  this  should  be  studied  in  Phase  B. 

7.5.10.2  Onboard  Command  Management 

The  SSDS  Study  has  proposed  a command  management  approach  which  involves  the 
scheduling  of  capabilities  (modes)  with  enforcement  by  means  of  electronic 
keys  and  reactive  control.  Actual  payload  uplink  data  is  transparent  to  the 
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SSDS . Changes  in  this  approach  would  have  a major  impact  on  the  ground  flow  of 
uplink  traffic  and  on  missing  coordination  of  the  ground  system  and  should  be 
examined  in  Phase  B. 

7.5.10.3  Packetization 

Obviously  the  ground  system  is  most  affected  by  the  assumption  of  all  data 
being  in  the  form  of  identical  self  identifying  telemetry  and  telecommand 
packets.  Changes  in  this  assumption,  for  example,  if  high  rate  payloads  are 
not  packetized  — would  have  major  ground  system  impacts,  as  noted  above. 

7.5.10.4  On-board  Optical  Disks 

The  proposed  ground  segment  design  assumes  the  use  of  on-board  optical  disks, 
which  allow  playback  in  a forward  direction.  The  backup  technology  is  that  of 
tape,  which  plays  back  in  reverse.  Level  0 processing  is  impacted  if  this 
occurs,  since  tape  reversal  is  required. 


7.5.11  Space/Ground  Transfer  Layer  Services 

It  is  recognized  that  a guaranteed  delivery  service  for  the  transmission  of 
error— sensitive  data  (assumed  to  be  low  rate)  is  desirable  for  the 
space/ground  link.  Such  a service,  such  as  the  CCSDS  transfer  layer  service, 
would  be  provided  on  a frame  basis  by  the  Data  Handling  Center  in  conjunction 
with  the  onboard  C&T  system.  Design  is  pending  recommendations  from  the  CCSDS 
on  modifications  to  the  transfer  layer  standards  to  support  a bi-directional 
"command  class"  service. 

7.5.12  Conclusion 

In  summary,  this  definition  of  the  Ground  SSDS  has: 

• Partitioned  and  allocated  functions  to  ground  facilities: 

- Data  Handling  Center 

Level  0 Processing  Facilities 
Control  Centers  (SSOCC,  COPCC,  POPCC) 
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- Engineering  Data  Centers 

- Ground  Services  Center 

- Payload  Operations  Control  Centers 

• Presented  key  operational  features  for 

- core  engineering  data  management 

- uplink  command  data  management 

- payload  data  management 

- mission/operations  coordination 

• Provided,  for  each  facility 

- an  interface  description  to  other  ground  elements 

- a function  desciption,  describing  in  more  detail  what  the 
facility  will  do 

- design  approach 

• Summarized  key  sensitivities  and  issues  which  impact  the  ground 
system. 
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8.0  SYSTEM  DEVELOPMENT  CONCEPTS 


8.1  Hardware  Development/Procurement 

Hardware  development/procurement  strategies  can  be  divided  into  two 
categories;  those  for  ground  system  hardware  and  those  for  space  element 
hardware.  Because  of  differences  in  the  operational  environments,  it  is 
expected  that,  in  general,  there  will  not  be  extensive  hardware  commonality 
between  these  different  domains.  There  is  potential  for  commonality  in  the 
exploitation  of  advanced  hardware  technology  development  even  though  the 
physical  implementation  of  the  technology  may  be  different,  (i.e.,  optical 
disk  buffering  technology  may  be  applied  to  both  ground  and  space  elements). 
This  study  has  primarily  focused  on  strategies  for  space  hardware 
development/procurement . Ground-based  systems  will  generally  use  commercially 
available  hardware  products  and  traditional  procurement  practices  will  be 
employed.  Some  specialized  hardware  development  for  high  data  rate 
interfacing  equipment  can  be  anticipated  for  certain  ground  elements  but  this 
does  not  pose  any  unique  procurement  problems.  While  there  are  significant 
advantages  to  establishing  some  level  of  commonality  for  ground-based  hardware 
(especially  data  processors),  it  is  recognized  that  there  are  realities  that 
will  tend  to  inhibit  this  strategy  (i.e.,  use  of  existing  equipment,  broad 
range  of  requirements,  etc.).  However,  some  level  of  commonality  for  newly 
procured  ground  hardware  should  be  considered  by  NASA  where  appropriate.  This 
is  especially  advantageous  within  each  NASA  center  since  training  and 
maintenance  costs  can  be  minimized.  In  addition,  when  there  is  sufficient 
functional  commonality  across  multiple  centers  (i.e.,  SSE's,  control  centers, 
etc.),  common  hardware  will  promote  software  portability  and  reusability  as 
well  as  simpler  interfaces. 

The  operational  environment  of  space  elements  impose  unique  requirements  for 
hardware  procurement/development  strategies  that  include  the  following: 

a.  Space  environment  (radiation,  etc.) 

b.  Physical  constraints  (size,  weight,  power) 
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c.  Reliability 

d.  Maintainability 

e.  New  technology  accommodation 

In  addition,  the  requirements  in  some  areas  wary  significantly  across  the 
various  space  elements  due  to  differences  in  orbit  (radiation)  and 
habitability  (reliability/maintainability).  These  requirements  generally 
apply  to  modular  hardware  components  of  the  onboard  DMS  that  includes  the 
following  key  items  described  in  section  6: 

a.  Network  Interface  Unit  (NIU) 

b.  Subsystem  Data  Processor  (SDP) 

c.  Mass  Storage  Devices 

d.  Multi-Purpose  Applications  Consoles  (MPAC) 

An  evaluation  of  the  requirements  defined  above  will  reveal  many  of  the  design 
features  for  an  SDP  that  are  common  to  many  prior  flight/space  applications. 
That  is  the  SDP  must  be  low  weight/volume/power,  modular  design,  and  space 
qualified  (to  levels  required)  as  well  as  provide  the  throughput  and  storage 
capacity  that  technology  will  support  for  1992  IOC.  However,  there  are 
certain  aspects  of  these  requirements  that  are  somewhat  unique  to  the  space 
station  program  due  to  the  habitability  environment,  the  goals  for 
automat ion/autonomy , and  the  need  to  plan  for  substantial  growth  over  the 
lifetime  of  the  space  station.  The  issues  related  to  these  unique  aspects 
that  pertain  to  space  hardware  development/procurement  strategies  are 
addressed  in  the  following  sections. 

8.1.1  SDP  Commonality 

The  concept  of  a common  (standardized  within  the  SSP)  SDP  for  onboard 
applications  has  several  cost-effective  benefits  for  the  SSP.  Primary 
motivation  includes  the  following  advantages: 
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a.  Maintainability  and  space  parts  inventory 

b.  Enhanced  architectural  flexibility  to  support  fault  tolerance,  design 
extendability,  and  other  architecture  adaptability  needs. 

c.  Promote  transportability  and  reusability  of  software. 

d.  Lower  development  and  operational  cost3  due  to  the  many  advantages 
the  SSE  can  provide. 

To  take  advantage  of  these  substantial  benefits,  it  is  necessary  to  address 
two  important  issues:  (1)  will  a common  SDP  adequately  meet  the  needs  of  all 
subsystems  (IOC  and  growth)?,  and  (2)  how  can  new  SDP  technology  be 
incorporated  during  evolutionary  growth?  These  issues  were  addressed  by  this 
study  at  two  distinct  levels  of  commonality;  (1)  across  space  elements,  and 
(2)  within  a space  element  (SS,  COP,  POP). 

In  evaluating  the  commonality  of  SDP's  across  space  elements,  it  is  clear  that 
significant  differences  exist  in  the  operational  environment  (radiation, 
habitability).  If  a common  SDP  were  adopted  it  would  have  to  be  designed  to 
meet  the  more  stringent  requirements  (radiation,  reliability,  maintainability) 
of  the  POP.  It  can  be  argued  that  if  an  SDP  is  to  be  developed  anyway  for  the 
POP  (non-recurring  cost  absorbed),  the  only  penalty  is  the  additional 
recurring  cost  when  applied  to  other  elements.  However,  the  potential 
advantages  identified  earlier  (a-d)  are  somewhat  mitigated  by  the  autonomous 
operation  and  unique  servicing  requirements  of  these  elements.  The 
transportability  and  reusability  of  software  is  still  an  important 
consideration  but  can  be  accommodated  with  a standardized  Instruction  Set 
Architecture  (ISA)  rather  than  a common  SDP.  This  study  recommends  that  a 
standard  ISA  be  adopted  across  space  elements.  However,  due  to  substantial 
differences  in  operational  requirements , a common  SDP  may  not  be  recommended 
for  all  space  elements.  This  will  be  further  evaluated  as  COP/POP 
requirements  and  designs  are  developed. 

The  advantages  of  SDP  commonality  are  much  more  apparent  within  a space 
element  (i.e.,  space  station).  This  study  strongly  recommends  that  a common 
SDP  be  adopted  for  IOC.  However,  there  is  a related  issue  yet  to  be  resolved; 
i.e.,  should  an  SDP  be  "tailorable"  to  specific  subsystems  needs  such  as 
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optional  I/O  "cards"  or  variations  in  memory  capacity.  Such  variations  imply 
a different  replacement  and  spare  parts  inventory  strategy. 

The  more  important  issue  is  how  to  realize  the  benefits  of  commonality  without 
unnecessarily  constraining  the  incorporation  of  new  technology  for 
evolutionary  growth.  It  is  recognized  that  long-term  growth  must  accommodate 
not  only  upgraded  versions  of  conventional  processors  (faster,  more  memory) 
but  also  radically  different  architectures . If  NASA  goals  for  advanced 
automation  are  even  partially  realized  during  growth  phases,  an  Al-oriented 
computer  architecture  may  become  an  essential  component  of  onboard  networks. 

To  maximize  the  advantages  of  SDP  commonality  while  promoting  growth,  this 
study  recommends  the  following: 

a.  Adopt  common  SDP  for  IOC 

b.  Accept  the  fact  that  onboard  networks  will  become  heterogeneous 
during  growth  and  plan  for  it. 

— Minimize  and  control  number  of  new  types  of  SDP 

Standardize  ISA  for  conventional  architectures  (MIL-STD  1750) 

- Design  networks  and  related  operating  system  to  promote  growth 
and  not  preclude  heterogeneous  systems. 

- Standardize  NIU  interfaces. 

8.1.2  Space  Qualification 

Space  qualification  is  that  effort  required  to  insure  that  hardware  elements 
will  meet  all  performance  requirements  in  the  specified  operational 
environment. 


Prior  space  qualification  programs  have  typically  exposed  samples  of  the 
target  hardware  to  an  exhaustive  sequence  of  environmental,  electro-magnetic 
and  power  tolerance  testing  with  levels  significantly  in  excess  of  mission 
profiles.  A successful  test  sequence  not  only  demonstrated  compliance  with 
requirements,  but  also  insured  that  normal  acceptance  testing  did  not 
significantly  fatigue  the  subsequent  production  units. 
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The  project  hardware  was  generally  new  development,  tailored  to  the  specific 
application  and  influenced  by  the  qualification  requirements  to  provide  overly 
rugged  enclosures,  components  and  mounting.  The  hardware  conservatism  of  the 
design  and  test  requirements , however,  were  generally  applied  because: 

1)  the  hardware  was  operational  through  the  severe  mechanical 
environments  of  launch  and  vehicle  staging, 

2)  failures  were  generally  intolerable,  and 

3)  fault  tolerance  was  generally  limited  to  static  redundancy  techniques 
because  of  the  continuing  physical  (size,  weight,  and  power) 
constraints . 

The  Space  Station  program  represents  a significant  departure  from  the  above 
scenario  because  it  will  be  manually  assembled,  activated,  and  repaired  on 
orbit.  This  implies  that  the  hardware  (electronic)  modules  within  each  launch 
package  need  not  be  operational  during  the  boost  operation  and  can  be  packaged 
to  survive  the  launch  and  staging  stresses. 

These  differences  provide  opportunities  for  innovative  qualification 
approaches  during  IOC  and  growth  phases  that  satisfy  identified  programmatic 
goals  of  cost,  commonality,  protof lighting,  technology  accommodation  and 
growth . 


The  key  to  maintaining  program  cost  goals  will  be  the  minimization  of 
development  effort  without  significantly  impacting  subsequent  operational 
costs.  Thi3  can  be  accomplished  in  many  cases  by  "buffering"  or  isolating  the 
environment  (i.e.  shielding,  mechanical/thermal  isolators,  etc.)  to  match 
existing  hardware  capabilities  rather  than  requiring  hardware  with  inherent 
environmental  compatibility. 

Lower,  more  tolerable  environmental  exposure  levels  will  allow  reduction  or 
elimination  of  selected  qualification  tests  with  more  reliance  on 
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qualification  by  similarity  (if  used  on  other  programs)  as  well  as  computer 
based  simulation  and  analysis.  This  approach  will  minimize  fatigue  on 
qualification  samples  and  is  therefore  supportive  of  protof lighting  goals. 

The  mechanical  environments  are  considered  to  be  primary  driver  for  any  space 
design.  For  the  Space  Station/Platform  equipment,  these  environments  are 
essentially  limited  to  the  boost  operation,  during  which,  the  transported 
packages  need  not  be  operational.  The  launch  configuration  of  each  package  is 
therefore  a variable  within  the  constraints  of  pre-launch  checkout  and 
assembly  limitations.  This  suggests  the  use  of  special  packaging/handling 
equipment  to  isolate  the  electronic  modules  associated  with  each  package  for 
the  boost  operation  environments. 

Space  radiation  will  be  a significant  factor  for  some  space  elements  of  the 
SSDS  (i.e.,  POP),  but  is  not  expected  to  be  a driver  for  the  inhabited  Space 
Station  itself  unless  commonality  across  space  elements  is  warranted . 

Shielding  and  other  design  options  should  be  fully  explored  before  discarding 
the  commonality  goals  and  initiating  new  development  activity. 

The  qualification  program  must  also  address  technology  insertion  and  growth 
components  since  they  will  be  subjected  to  the  same  basic  environments.  This 
follow-on  hardware  will  generally  be  transported  as  loose  items,  therefore, 
the  special  handling  (environmental  isolation)  equipment  discussed  earlier, 
will  be  more  viable. 

With  respect  to  the  qualification  effort,  the  study  recommends: 

a.  Utilization  of  available  techniques  to  reduce  direct  environmental 
exposure  (shielding,  mechanical/thermal  isolators). 

b.  Analysis/utilization  of  prior  qualification  history  of  commercial 
hardware  candidates  for  potential  qualification  requirement 
reductions  (i.e.,  qualify  by  similarity). 
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c.  The  rigor  of  testing  can  be  relaxed  based  on  the  number  of  flight 
units.  Small  quantities  can  be  effectively  bench  tested  utilizing 
"golden  box"  techniques  as  opposed  to  the  required  production  test 
equipment,  training  and  formalization  of  high  volume  projects. 

8.1.3  Technology  Capture 

Historically,  NASA  space  programs  have  incorporated  data  processing  hardware 
technology  that  significantly  lags  the  current  state-of-the-art.  There  are 
many  contributing  factors  that  combine  to  cause  this  situation  including 
stringent  mission/environmental  requirements  and  the  availability  of  space 
qualified  hardware.  In  particular,  space  radiation  qualification  has  always 
been  an  expensive  and  time  consuming  activity.  This  generally  does  not 
present  a problem  if  onboard  processing  demands  are  low  and  sufficient  margin 
is  provided  for  unanticipated  changes  during  development  (almost  never  the 
case).  Onboard  processing  capability  has  often  been  traded  off  for  low  power 
demands,  small  volume/weight,  and  high  reliability  at  the  expense  of 
autonomous  operation.  Failure  to  minimize  this  "technology  gap"  for  the  space 
station  program  could  seriously  jeopardize  NASA  goals  for  a high  degree  of 
space  station  autonomy  and  automation. 

While  certain  space  station  mission/environmental  requirements  are  unique 
(habitation)  and  offer  the  enhanced  opportunity  for  capturing  commercial 
technology,  these  requirements  are  also  very  diverse  across  space  elements 
(SS,  COP,  POP).  This  may  result  in  substantial  variations  on  the  degree  to 
which  commercial  technology  can  be  applied  across  elements.  Space  radiation 
environments  are  likely  to  be  a key  driver  for  the  POP. 

The  following  steps  have  potential  for  minimizing  the  "technology  gap". 

a.  Selection  of  a standard  ISA  early  in  the  program  and  defer  the 

selection  of  the  actual  target  hardware.  This  will  allow  initial 
software  development  to  commence  on  schedule  (long-lead  item). 

Initial  code  and  checkout  can  be  accomplished  on  an 
emulator/simulator  with  target  hardware  required  for  subsequent  test 
and  integration. 
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b.  Adopt  widely-supported  applicable  standards  to  broader  base  of 

potential  suppliers.  This  will  substantially  reduce  the  need  for 
special  development  activities  which  often  become  long-lead  items. 

In  particular,  the  use  of  military  standards  (i.e.,  MIL-STD-1750) 
will  not  only  provide  a rich  source  of  flight/space  qualified 
components,  but  a highly  visible  growth  path  supported  by  DOD  (VHSIC, 
DARPA,  etc . ) . 

8 . 2 SOFTWARE  DEVELOPMENT 
8.2.1  INTRODUCTION 

The  purpose  of  the  SSE  is  to  provide  an  environment  to  support  the  development 
of  software  for  the  Space  Station.  The  SSE  is  a set  of  tools  which  are 
portable  and  will  be  made  available  for  subsystem  and  payload  developers.  The 
tools  included  in  the  SSE  will  not  dictate  a specific  methodology  or  set  of 
procedures.  The  users  will  be  able  to  define  their  procedures  (with  NASA 
approval)  and  utilize  subsets  of  the  tools  as  required  to  support  those 
procedures. 

The  primary  goal  of  the  SSE  is  to  reduce  the  life  cycle  cost  and  insure  the 
quality  of  all  software  produced  for  the  Space  Station.  This  includes  core, 
payload,  ground  support,  and  SSE  software.  This  will  be  accomplished  by  the 
achievement  of  the  following  subgoals: 

1.  Provide  a stable,  common  base  for  the  development  of  the  software. 

2.  Provide  integrated  support  of  the  entire  software  life  cycle,  from 
conceptual  definition  through  delivery,  including  configuration  management 
at  all  stages. 

3.  Provide  easily  attainable  status  at  many  levels  by  providing  tools  which 
facilitate  definition,  scheduling  and  tracking  of  intermediate  milestones. 
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4.  Provide  state  of  the  art  tools  for  each  task  in  the  software  life  cycle  to 
increase  overall  productivity. 

5.  Provide  a common,  convenient  interface  for  each  of  the  tools  to  avoid  the 
necessity  of  learning  multiple  interfaces. 

6.  Provide  an  easy  way  to  expand  the  tool  set  in  order  to  add  new  tools. 

7.  Provide  a method  of  maintaining  multiple  versions  of  all  documentation 
such  that  it  is  available  on-line  or  it  can  be  printed. 

8.  Provide  tools  which  support  and  encourage  commonality  and  the  reuse  of 
existing  components. 

9.  Provide  sufficient  flexibility  within  the  configuration  management  and 
software  engineering  methodology  support  to  make  the  SOE  attractive  to 
payload  customers  as  well  as  satisfying  the  needs  of  core  and  ground 
software  developers. 

10.  Provide  SSE  capabilities  such  that  support  provided  is  independent  of 
users  physical  location. 

The  types  of  software  support  by  the  SSE  will  include: 

• Real  Time  Flight  Software 

• Ground  Command  and  Control  Software 

• Ground  Data  Processing  Software 

• Support  Software 

• Integration  and  Test  Software 

• Emulation  and  Model  Software 

• Customer  Application  Software 

In  this  document,  the  term  "user  group"  will  be  used  to  define  some  set  of 
users  which  is  working  on  the  same  task  and  requires  the  same  functions  from 
the  SSE. 


8-9 


The  SSE  will  be  used  by  development  groups  to  generate  software  elements,  and 
by  the  software  integration  site  to  combine  the  elements  into  integrated 
software  loads.  The  support  provided  to  each  development  user  group  will  be 
identical.  This  support  will  be  provided  in  a manner  which  will  allow  each 
group  to  develop  their  applications  as  autonomously  as  possible,  but  will 
encourage  communications  and  software  commonality  among  the  groups.  This  is 
depicted  in  Figure  8.2-1.  Each  function  in  the  figure  is  described  in  more 
detail  in  this  document.  The  support  for  the  integration  will  consist  of  many 
of  the  same  functions  as  provided  for  the  development  groups,  but  it  will  also 
include  facilities' to  integrate  the  software  produced  by  all  and  it  will 
provide  more  extensive  system/integration  test  facilities.  See  Figure  8.2—2. 

8.2.2  CONFIGURATION  CONTROL  AND  MANAGEMENT  SUPPORT 

A set  of  tools  will  be  provided  by  the  SSE  to  support  Configuration  Control 
and  to  support  management  in  their  activities  of  planning  and  resource 
allocation.  It  is  assumed  that  to  maintain  configuration  control  over  the 
Space  Station  software,  the  project  will  utilize  a series  of  NASA  and 
contractor  control  boards  (similar  to  what  has  been  used  in  previous  NASA 
projects)  and  an  automated  data  base  system  for  storing  and  enforcing 
decisions  made  by  the  boards.  These  tools  will  provide  the  functions 
discussed  below. 

8.2.2. 1 CONFIGURATION  MANAGEMENT  DATA  BASE 


The  Configuration  Management  Data  Base  is  the  repository  for  all  of  the 
configuration  control  and  management  support  data.  While  thought  of  as  a 
single  data  base,  it  is  in  actuality  composed  of  several  logically  related 
data  bases.  Each  contains  the  level  of  information  which  allows  its  users 
(i.e.,  management,  development,  testing)  to  plan,  schedule  and  track  its  work. 

Proposed  software  updates  will  be  documented  in  the  data  base.  The  control 
boards  will  coordinate  a review  of  the  proposed  updates  by  applicable  project 
members  to  determine  the  benefits,  cost  and  impacts  of  the  update.  Results  of 
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SOFTWARE  SUPPORT  ENVIRONMENT 
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Figure  8.2-1.  Software  Development  Site  Support 
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Figure  8.2-2.  Software  Integration  Site  Support 


the  review  will  be  stored  in  the  data  base.  The  boards  will  then  disposition 
the  proposed  updates  and  determine  the  implementation  schedule.  The  control 
board  structure  is  currently  undefined.  A proposed  structure  is  depicted  in 
Figure  8.2-3.  The  approval  levels  required  for  updates  will  have  to  be 
determined  based  on  factors  such  as  cost  of  change,  number  of  systems 
impacted,  etc.  All  data  will  be  retained  in  the  data  base  and. will  be  used  as 
inputs  to  other  functions.  See  Figure  8.2-4. 

8 . 2 . 2 . 2 SUBFUNCTIONS 

8. 2. 2. 2.1  DEFINITION  OF  SOFTWARE  INCREMENTS 

The  Configuration  Control  function  of  the  SSE  will  provide  a method  for 
defining  and  managing  software  increments.  Some  of  the  increments  will  be 
intermediate  systems  used  by  the  development  groups  to  checkpoint  their 
progress  and  others  will  be  released  for  further  integration. 

For  each  increment  a set  of  data  is  maintained.  This  data  includes  the 
increment's  name,  dates  associated  with  milestones  in  the  increment's  life 
(definition,  build,  release,  delivery),  and  the  increment's  status  (defined, 
baselined,  integrated,  delivered).  This  data  will  provide  a means  of  tracking 
and  controlling  increments  and  of  producing  reports  about  system  activity  on 
the  increments. 

8. 2. 2. 2. 2 DEFINITION  OF  SOFTWARE  CAPABILITIES 

The  CM  function  of  the  SSE  must  provide  a method  of  identifying  changes  which 
must  be  made  in  the  software  being  implemented.  There  are  two  basic  types  of 
changes;  those  which  provide  enhancements  (and  usually  imply  requirements 
updates)  and  those  which  correct  errors  in  existing  software.  All  changes 
will  be  documented  by  a 'control  instrument'.  This  is  a generic  term  which 
will  be  used  in  place  of  a multitude  of  specific  terms  such  as  Change  Request 
(CR),  Problem  Trouble  Report  (PTR),  Engineering  Support  Request  (ESR),  etc. 

The  SSE  must  provide  for  maintenance  of  data  pertaining  to  all  control 
instruments.  The  primary  information  includes  identifying  information  of  the 
control  instrument  (number,  title)  and  identification  of  the  software 
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Figure  8.2-3.  Review  Board  Structure 
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Figure  8.2-4.  Space  Station  Configuration  Control  and  Management  Support 


increments  to  which  the  instrument  applies.  Depending  on  the  type  of  control 
instrument  and  on  the  needs  of  the  subsystem  to  which  the  control  instrument 
applies,  other  data  can  also  be  retained.  This  data  might  include  more 
details  about  the  control  instrument's  initiation  (initiator  name  and  address, 
reason  for  initiation,  description),  assessments  (lines  of  code,  core/CPU 
impacts,  manpower),  and  affected  elements  (modules,  documents,  test  cases).  A 
particular  kind  of  control  instrument  might  have  unique  data.  For  example,  an 
instrument  documenting  an  error  might  have  quality  improvement  data  associated 
with  it  (how  error  found,  where  error  created,  how  error  can  be  avoided). 

Whenever  a control  instrument  is  entered  into  the  CM  function,  the  appropriate 
control  board  is  automatically  notified  and  is  sent  the  initial  information 
regarding  the  instrument.  As  the  control  instrument  is  evaluated  by  the 
control  boards  and  those  affected,  additional  data  is  generated  and  is  entered 
into  the  CM  system. 
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8. 2. 2. 2. 3  ASSIGNMENT  OF  CAPABILITIES  TO  INCREMENTS 


As  a result  of  the  control  board  review,  each  control  instrument  is  assigned 
for  implementation  on  one  or  more  increments.  The  capability  to  make  this 
assignment  must  be  restricted  to  authorized  users  who  represent  the 
configuration  control  boards.  The  Build  and  Delivery  system  (discussed  in 
"System  Build  and  Integration")  which  creates  each  increment  will  incorporate 
only  the  control  instruments  assigned  to  that  increment.  This  provides  a 
single  point  of  control  for  each  entity  to  be  baselined  in  a given  system 
release.  A single  change  can  close  several  control  instruments. 

8. 2. 2. 2. 4 SCHEDULING  AND  TRACKING  OF  PROGRESS 

The  CM  function  must  include  the  capability  to  schedule  intermediate 
milestones  of  the  implementation  process.  It  must  also  provide  the  capability 
to  extract,  integrate,  format  and  report  scheduling  data  at  all  levels  of  the 
Space  Station  project,  from  individual  module  updates  to  major  project 
enhancements  which  span  multiple  sites  and  user  groups.  Through  this 
facility,  managers  are  able  to  extract  scheduling  information  with  which  to 
plan  the  control  and  use  of  departmental,  project  and  system  resources. 

Through  the  intermediate  and  final  data  entered  for  each  change  authorization, 
a detailed  schedule  can  be  produced  tracking  all  steps  in  the  progression 
toward  the  final  implementation  of  the  change  or  problem  fix.  Where  conflicts 
occur  (either  with  resources  or  personnel)  the  scheduling  data  should  enable 
the  manager  to  identify  problem  areas  quickly  and  institute  alternate  plans. 

8. 2. 2. 2. 5 DATA  AVAILABILITY 

The  CM  function  must  provide  NASA  and  development  managers  with  visibility 
into  the  capabilities  being  implmented,  their  schedules,  status,  etc.  This 
will  be  provided  via  online  data  base  queries  and  hardcopy  report  generation. 
Menus  and  commands  will  be  provided  by  which  the  user  may: 

• invoke  queries  and  reports  predefined  in  the  system; 

• define  and  save  (if  desired),  new  queries  or  reports; 

• invoke  the  new  queries  and  reports. 


8-16 


8. 2. 2. 2. 6  ACCESS  CONTROL 


Since  control  instruments  may  have  dependencies  on  other  instruments  not  under 
the  authority  of  the  same  user,  the  query  and  report  facility  must  include 
several  levels  of  access  control  to  prevent  unauthorized  access  to  data 
belonging  to  one  user  by  another.  Further,  the  facility  should  include  the 
ability  to  suppress  the  display  and/or  print  of  selected  data  fields  in  a 
record  based  on  the  level  of  access  control  granted  to  a user. 

8. 2. 2. 2. 7 HISTORICAL  REFERENCE. 

The  capabilities  of  each  increment  and  all  scheduling  data  must  be  kept  to 
provide  a permanent  record  of  the  activities  of  the  project.  This  data  must 
be  available  in  formats  similar  to  that  mentioned  in  the  section  on  scheduling 
and  tracking. 

8. 2. 2. 2. 8 INTERFACE  WITH  TMIS 

The  CM  function  must  interface  with  the  TMIS  system.  Many  of  the 
configuration  control  actions  recorded  in  the  TMIS  will  result  in  generation 
of  control  instruments  within  the  SDE  configuration  management  system.  For 
these  cases,  a cross-reference  capability  must  exist.  The  TMIS/SSE  interface 
should  also  include  items  such  as  costing  statistics,  scheduling  data,  board 
approvals,  user  groups  affected,  and  status.  The  disposition  (approval, 
disapproval,  schedule)  of  a control  instrument  in  the  TMIS  must  take 
precedence  over  local  user  disposition. 

8. 2. 2. 2. 9 INTERFACE  BETWEEN  USER  GROUPS 

The  CM  function  mu3t  be  implemented  in  such  a way  as  to  encourage 
communication  among  user  groups  to  facilitate  overall  project  integration  and 
scheduling  while  also  providing  appropriate  levels  of  security.  The 
capability  for  one  user  group  to  identify  dependencies  on  other  user  groups 
must  be  included. 
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8. 2. 3.0  REQUIREMENTS  GENERATION  AND  ANALYSIS 


Requirements  Generation/Analysis  provides  a foundation  for  software  by 
identifying  interface  details,  providing  descriptions  of  functions, 
determining  design  constraints,  and  defining  software  validation  requirements . 
On  a project  as  large  and  complex  as  Space  Station,  each  of  the  afore 
mentioned  are  crucial  to  maintain  communication  between  the  requirements 
initiator  and  the  software  developer.  Figure  8.2-5  represents  the  scenario 
used  to  modify  requirements . 

8.2.3. 1 SUBFUNCTIONS 

8. 2. 3. 1.1  MAINTAIN  MULTIPLE  LEVELS  OF  SOFTWARE  REQUIREMENTS 

The  Requirements  Generation  Function  must  provide  the  capability  to  support 
multiple  levels  of  software  requirements  such  as  conceptual,  functional,  and 
detail.  The  top  level  of  Software(S/W)  Requirements  is  refered  to  as  Level  A 
S/W  Requirements  or  Conceptual  S/W  Requirements.  Next  are  Level  B S/W 
Requirements  or  Functional  S/W  Requirements  and  the  lowest  level  of  S/W 
requirements  is  Level  C S/W  Requirements  or  Detailed  S/W  Requirements.  At 
each  requirements  level,  there  needs  to  be  a tool  to  validate  that  all 
input/output  table  entries  are  defined. 

8. 2. 3. 1.2  PROVIDE  SUPPORT  FOR  INTERFACE  CONTROL  DOCUMENTS 

The  Requirements  Generation  Function  must  also  support  Interface  Control 
Documents (ICD)  in  the  same  manner  as  software  requirements . ICD's  should  have 
input/output  tables  that  a tool  can  verify  the  consistency  across  all  ICS's. 

8.2.3. 1.3  PROVIDE  TRACEABILITY  OF  REQUIREMENTS 


Software  requirements  levels  must  be  traceable  from  Request  for  Proposal 
through  software  design  to  insure  consistency  of  requirements . At  every  level 
except  the  first  level,  each  requirements  section  must  list  the  reference 
requirements  sections  from  the  previous  level.  A tool  will  validate  that  the 
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referenced  requirements  sections  exist.  Later,  another  tool  will  validate 
that  all  sections  from  the  previous  level  have  been  referenced  at  the  current 
level  and  the  tool  will  list  any  unreferenced  sections  from  the  previous 
level.  Multiple  versions  of  requirements  must  be  supported  to  provide 
traceability  between  CM  increments. 

8. 2. 3. 1.4  PROVIDE  TRACEABILITY  TO  CM  CONTROL  INSTRUMENT 

Each  requirements  section  to  be  modified  must  reference  a CM  control 
instrument,  thus  providing  traceability  to  all  versions  of  software 
requirements  that  must  be  supported. 

8. 2. 3. 1.5  PROVIDE  A STRUCTURED  REQUIREMENTS  LANGUAGE 

Make  available  a structured  requirements  language  for  use  if  required.  This 
language  should  be  such  that  requirements  can  be  described  with  a 
specification  language  that  combines  keyword  indicators  with  a natural 
language  narrative.  The  specification  language  is  fed  to  a processor  that 
produces  a requirements  specification  and  a set  of  diagnostic  reports  about 
the  consistency  and  organization  of  the  specification. 

8. 2. 3. 1.6  PROTOTYPING 

In  order  to  allow  for  early  checkout  of  requirements  concepts,  tools  such  as 
display  design  and  graphic  analysis  must  be  available  which  support  rapid 
prototyping  of  executable  software  representing  the  requirements . 

8. 2. 3. 1.7  PROJECTED  SYSTEMS  PERFORMANCE 

Tools  must  be  provided  to  enable  early  system  performance  modeling.  Input 
requirements  to  this  type  of  tool  are  measures  in  terms  of  cycles  per  second, 
CPU  demand  on  the  system,  and  queue  contention  within  the  system.  However, 
the  original  estimates  for  memory  sizing  and  CPU  demand  are  made  by  the 
analyst  based  upon  knowledge  of  the  system. 
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8. 2. 3. 2 CHARACTERISTICS 


In  order  for  these  functions  to  be  useful  to  the  project,  they  must  be 
provided  in  a simple,  consistent,  straight-forward  manner.  All  the  data  must 
be  stored  using  a data  base  manegement  system  which  facilitates  on-line 
queries,  report  generation  and  quick  response  time.  It  must  also  support 
assignment  of  various  levels  of  security  (access,  update,  create  and  delete 
authority)  over  the  data  in  the  data  base.  Requirements  maintenence  must  be 
configuration  controlled  (tracked  to  control  instrument  approval)  and  made  as 
part  of  the  integration  process. 

8. 2. 4.0  DESIGN  AND  CODE  GENERATION 

Design  and  code  generation  is  the  process  by  which  programmers  create  new 
software  and  make  changes  to  previously-created  software.  Because  the  process 
is  a creative  one,  it  tends  to  rely  heavily  on  manual  inputs  made  by  skilled 
humans.  In  order  to  generate  software  for  the  Space  Station  in  the  most 
cost-effective  manner,  the  SSE  must  provide  tools  to  assist  the  human 
programmer  in  designing  and  coding  in  the  most  efficient  and  errorfree  manner 
possible.  See  Figure  8.2—6  for  a summary  of  the  process. 

8.2.4. 1 SUBFUNCTIONS 

8.2.4. 1.1  DESIGN  TOOLS 

Tools  must  be  provided  to  allow  software  designers  to  create  a representation 
of  the  software  at  multiple  design  levels.  Tools  which  allow  generation  and 
presentation  of  the  design  in  a graphic  format  must  also  be  supported. 
Provision  must  be  made  to  use  textual  design  languages  (e.g.,  PDL/Ada)  in 
cases  where  they  are  more  appropriate  than  graphics.  To  ensure  that  all 
documentation  is  complete  and  consistent,  automatic  checks  must  be  made 
between  the  design,  the  requirements  specification,  and  other  documentation 
(e.g. , users  guides) . 
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Figure  8.2-6.  Design  and  Code  Process 


8 . 2 . 4 . 1 . 2  EDITORS 


Language-reconf igurable  "smart"  editors  must  be  available  to  support  creation 
and  modification  of  software.  These  editors  must  be  capable  of  supporting 
insertion  of  software  control  structures,  syntax  analysis  of  entered  code,  and 
local  semantic  analysis  of  entered  code,  all  tailored  to  the  project's  and 
user  group's  coding  standards  and  to  the  language  of  the  code  being  edited. 

8. 2. 4. 1.3  STATIC  ANALYSIS 

Since  software  errors  are  less  costly  to  correct  when  they  are  found  soon 
after  they  are  inserted,  the  SSE  must  supply  tools  which  provide  static 
analysis  of  design  and  code  as  early  as  possible  (ideally  during  or 
immediately  following  an  edit  session).  This  analysis  will  include  standards 
checking  (project  and  user-group  defined),  syntax  checking,  data  flow 
analysis,  complexity  measures,  and  execution  performance  estimates. 


8. 2. 4. 1.4  INSPECTIONS 

Since  an  important  part  of  ensuring  quality  software  is  peer  review,  the  SSE 
must  provide  tools  which  assist  in  the  inspection  process.  These  tools  should 
aid  in  distributing  the  materials  to  be  reviewed  (mailing  lists,  automatic 
formatting  of  text),  assist  during  the  review  (multiple  windows,  notepads), 
and  provide  a repository  for  the  results  of  the  review  (history  data,  action 
items) . 

8. 2. 4. 1.5  UNIT  TESTING 

Unit  testing  is  a specialized  part  of  testing  which  applies  primarily  to  the 
code  developer.  The  SSE  must  have  the  capability  for  symbolic  execution  of 
code  and  for  executing  the  code  with  interactive  queries  and  control  at  the 
source  line  level.  See  "Testing  and  Analysis"  for  an  expanded  discussion  of 
testing . 
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8.2.4. 1.6  REUSABILITY 


There  are  two  types  of  tools  necessary  to  support  software  reusability.  First, 
there  must  be  tools  which  encourage  software  developers  to  use  existing 
components.  Second,  there  must  be  tools  which  allow  developers  of  components 
which  are  reusable  to  make  those  components  available  for  general  use. 

To  encourage  the  use  of  existing  components,  the  software  developer  must  have 
easy  access  to  a collection  of  reusable  software  components.  To  make  this 
possible,  three  things  are  needed: 

1.  a collection  of  data  describing  the  available  components 

2.  tools  which  use  that  data  to  help  find  the  components  needed  to  solve  a 
particular  problem 

3.  tools  to  tailor  a component  to  a user's  requirements  by  asking  questions 
about  the  intended  use  of  the  component  and  using  the  answers  with  a 
collection  of  knowledge  about  the  component  to  interactively  help  the  user 
create  a configuration  of  the  component  which  solves  the  user's  problem. 

Before  the  library  of  reusable  components  becomes  useful,  it  will  need  to  have 
a variety  of  components  added  to  it.  To  encourage  this  growth,  developers  of 
potentially  re-usable  components  must  be  encouraged- to  place  these  components 
into  the  library.  To  do  this,  tools  must  be  available  which  prompt  the  user 
to  enter  data  about  the  component  and  then  store  the  data  so  that  it  can  be 
used  by  the  tools  described  above  to  find  and  tailor  the  component. 

Reusable  software  components  will  be  treated  like  any  other  module  by  the 
tools  in  the  SSE  (e.g.,  library  management  and  source  element  configuration 
control  will  be  provided  by  the  normal  build  tools).  The  only  thing  different 
about  reusable  components  will  be  the  "reusability"  knowledge  associated  with 
them. 


8 . 2 . 4 . 1 . 7 STATUS 

To  assist  in  managing  his  time,  the  software  developer  must  be  able  to  track 
the  status  of  the  design  and  code  on  which  he  is  working.  Tools  which  provide 
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this  status  from  data  maintained  by  the  Configuration  Management  and  Build  and 
Delivery  functions  must  be  provided. 

8.2.4. 1.8  TRANSLATORS 

The  SSE  must  provide  support  for  a variety  of  translators.  This  includes 
translators  for  the  source  elements  of  traditional  programming  languages 
(e.g.,  compilers)  and  translators  for  other  types  of  source  elements  (e.g., 
documents  formatters  or  data  processors).  The  SSE  must  support  translators 
for  multiple  programming  languages  and  must  allow  multiple  translators  for  a 
single  programming  language  (e.g.,  for  different  target  environments).  The 
programmer's  interface  to  each  of  the  translators  must  be  similar. 

8 . 2 . 4 . 2 CHARACTERISTICS 

For  the  design  and  code  generation  tools  in  the  SSE  to  be  most  effective,  the 
user  of  these  tools  must  be  able  to  spend  the  maximum  amount  of  his  time  using 
the  tools  to  generate  software  rather  than  discovering  how  the  tools  work.  To 
accomplish  this  goal  the  following  must  be  true: 

• each  of  the  tools  must  have  an  interface  which  is  as  similar  as  possible 
to  the  other  tools'  interfaces. 

• the  user  must  be  able  to  produce  only  one  form  of  input  to  the  tools 
(e.g.,  the  program  source).  The  tools  must  be  able  either  to  use  that 
input  or  to  use  the  output  from  another  tool  as  input.  No  manual 
reformatting  of  data  for  the  various  tools  can  be  allowed. 

• the  inexperienced  user  must  be  able  to  see  a view  of  the  tools  which 
provides  step-by-step  guidance  (e.g.,  menus). 

• the  experienced  user  must  be  allowed  to  directly  invoke  tools  (e.g., 
commands) . 

• All  of  the  products  produced  by  the  programmer  must  be  accessible  on  line 
in  the  SSE.  This  includes  design,  code,  and  documentation. 
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8. 2. 5.0  SYSTEM  BUILD  AND  INTEGRATION 

The  System  8uild  and  Integration  function  of  the  SSE  provides  the  tools 
necessary  for  orderly  and  controlled  collection  and  integration  of  software 
systems  (and  their  associated  documentation  and  data)  by  their  developers  and 
testers  and. for  controlled  delivery  of  those  systems  to  their  users. 

-8.2.5. 1 SUBFUNCTIONS 

8.2.5. 1.1  HIERARCHY  MANAGEMENT 

The  Hierarchy  Management  function  allows  system  coordinators  to  define  and 
control  the  organization  and  flow  of  program  development  and  integration 
through  promotion  hierarchies.  See  the  section  called  "Promotion  Hierarchies" 
for  a more  detailed  description  of  promotion  hierarchies. 


8.2.5. 1.2  PROMOTION 

The  Promotion  function  provides  a controlled  mechanism  for  moving  modules  and 
subsystems  from  one  level  of  integration  to  the  next.  The  promotion  function 
locks  out  any  further  changes  and  makes  the  promoted  object  ready  for 
baselining  into  the  next  higher  subsystem  in  the  promotion  hierarchy. 
Promotion  is  allowed  only  if  the  proper  authorization  exists  in  the 
Configuration  Management  database. 

8.2.5. 1.3  BASELINE 

The  baseline  function  takes  objects  (modules  and  subsystems)  which  have  been 
promoted  into  a subsystem  and  makes  them  a permanent  part  of  the  subsystem. 
The  baseline  function  is  the  mechanism  by  which  increments  are  created  (as 
discussed  in  "Configuration  Control  and  Management  Support").  All  actions 
taken  by  the  baseline  process  are  recorded  in  the  subsystem's  history  file  or 
in  the  Configuration  Management  database. 
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8.2.5. 1.4  SUBSYSTEM  INTEGRATION 

Subsystem  Integration  performs  the  necessary  transformations  on  a baseline 
subsystem  to  put  it  in  the  format  necessary  for  the  subsystem's  integration 
level.  For  example,  the  baseline  function  may  only  operate  on  the  source 
element  of  modules  in  the  subsystem  (as  decided  by  the  subsystem 
coordinator) . The  subsystem  integration  function  in  this  case  might  be 
responsible  for  performing  the  translations  (e.g.,  compilations)  necessary  to 
make  the  subsystem  executable. 

8. 2. 5. 2 DEFINITION  OF  TERMS 

The  following  are  definitions  of  terms  used  in  the  Build  and  Integration 
section.  In  many  cases  these  definitions  represent  extensions  to  the  common 
definitions  of  the  terms. 

MODULE  Any  entity  which  is  conf igurat ion-control led  as  a logical  set.  For 
example,  a module  may  be  a program,  a data  table,  a test  case  or  a 
group  of  database  records,  A module  may  consist  of  several  elements 
(see  the  definition  of  element). 

ELEMENT  One  of  the  pieces  associated  with  a module.  Some  examples  of 

elements  of  a program  module  are  the  source,  the  object,  and  the 
compilation  listing. 

LIBRARY  A collection  of  modules  which  are  related  to  each  other.  A library 
may  consist  of  several  physical  files.  Typically,  libraries  will  be 
organized  by  subsystem  and  by  module  type  (for  example,  different 
applications  might  store  their  modules  in  separate  libraries  and  a 
single  application  might  store  its  source  and  table  modules  in 
separate  libraries. 

SOURCE  The  initially-generated  element  of  a module.  Thi3  is  probably 

manually  generated,  but  does  not  have  to  be.  The  common  example  is 
program  source.  Other  examples  include  unformatted  documentation, 
test  case  inputs,  and  unprocessed  data  records. 
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SUBSYSTEM 


A collection  of  modules  (and  associated  descriptive  and 
historical  data)  which  have  a common  purpose  or  use.  For 
example,  the  modules  associated  with  a particular  payload  might 
make  up  a subsystem.  Depending  on  the  level  of  integration,  a 
subsystem  might  contain  other  subsystems  as  subsets.  As  an 
example,  a subsystem  containing  documentation  modules  might  be 
made  up  of  subsystems  each  of  which  contains  the  modules  for  one 
of  the  volumes  of  the  complete  document. 


8. 2. 5. 3 CHARACTERISTICS 

8. 2. 5. 3.1  CONFIGURATION  CONTROL  OF  ELEMENTS 

The  build  function  supports  configuration  control  of  all  changes  to  the 
systems  being  built.  Changes  are  tracked  at  all  levels;  from  the 
system/subsy stem  level  down  to  the  source  line  level.  No  change  may  be 
promoted  to  or  baselined  into  a subsystem  without  proper  authorization  in  the 
Configuration  Management  database.  Once  an  authorized  change  is  begun 
(through  a controlled  retrieval  process),  no  other  user  can  make  authorized 
changes  to  the  same  module.  Temporary  trial  changes  are  allowed  at  any  point 
(e.g.,  for  proving  a concept),  but  are  not  accepted  by  the  build  functions. 
Information  retained  about  each  change  includes  the  reason  for  the  change 
(e.g.,  control  number)  and  the  subsystem  and  version  on  which  the  change  was 
made. 

8. 2. 5. 3. 2 PROMOTION  HIERARCHIES 

Promotion  hierarchies  represent  a planned  path  from  development  through 
integration  to  a delivered  system.  A separate  hierarchy  exists  for  each 
release  (delivery)  of  a system.  A system  is  divided  into  subsystems  which  are 
developed  independently  of  each  other.  As  each  subsystem  is  completed 
(possibly  after  several  cycles  of  updates  to  the  subsystem)  it  is  promoted  to 
the  next  level  where  it  is  integrated  with  other  subsystems. 
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Figure  8.2-7.  Initial  Promotion  Hierarchy:  This  is  an  example  of  a promotion  hierarchy  immediately  after  initial 
definition.  Only  the  user  libraries  ("U")  and  the  lowest  level  subsystems  are  defined  (solid  boxes). 
All  other  subsystem  nodes  in  the  hierarchy  are  planned  (dotted  boxes),  but  do  not  actually  exist. 


Changes  to  a system  are  done  only  to  the  lowest  levels  of  a hierarchy.  When 
planned  change  activity  and  testing  for  a subsystem  is  completed,  the 
subsystem  is  promoted  and  then  removed  from  the  hierarchy.  Users  who  need  to 
make  maintenance  changes  to  the  subsystem's  modules  are  connected  to  the 
higher  level  subsystem  which  now  contains  their  module. 

Figure  8.2-7  represents  a newly-defined  hierarchy  for  system  "A".  Note  that 
the  number  of  subsystems  between  the  users  (programmers)  and  the  delivered 
system  can  vary  depending  on  the  needs  of  each  subsystem.  Also  note  that 
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multiple  levels  of  integration  for  a single  subsystem  can  be  accommodated 
(shown  by  two  levels  for  subsystem  "C"  and  for  system  "A").  Figure  8.2-8  shows 
how  the  system  "A"  hierarchy  looks  after  some  initial  baselines  have  been 
established  for  two  of  the  subsystems  and  Figure  8.2-9  shows  how  the  hierarchy 
looks  when  most  of  the  subsystems  have  been  promoted  into  system  "A". 

8. 2. 5. 3. 3 PROMOTION 

Promotion  is  the  way  in  which  a module  or  subsystem  is  made  available  for  the 
next  level  of  integration.  A module  or  subsystem  is  promoted  when  the  current 
owner  is  satisfied  that  all  required  testing,  inspection,  integration,  etc. 
is  completed.  Promotion  can  take  place  only  if  the  appropriate  authorization 
exists  in  the  Configuration  Management  database.  Once  promotion  takes  place, 
the  promoted  entity  is  locked  and  no  more  changes  can  be  made  to  it  without 
the  approval  of  the  coordinator  for  the  target  subsystem. 

Module  promotion  moves  a module  from  a user  library  to  the  collection  pool  for 
a subsystem.  Module  promotion  can  only  be  initiated  by  the  responsible 
programmer  defined  in  the  promotion  hierarchy  for  that  subsystem.  At  a 
minimum,  the  module  source  is  promoted,  but  (depending  on  the  rules  determined 
by  the  subsystem's  management)  all  elements  of  the  module  may  be  promoted. 

Subsystem  promotion  sets  up  pointers  in  the  collection  pool  for  the  subsystem 
at  the  next  level  of  the  promotion.  The  rules  determined  by  the  next  higher 
level  subsystem's  coordinator  determine  whether  the  promoted  subsystem  is 
copied  or  simply  pointed  to  and  whether  all  elements  or  only  source  elements 
take  part  in  the  promotion. 

8. 2. 5. 3. 4 DELIVERY 

When  all  changes,  integration,  and  testing  for  a system  are  completed,  the 
system  can  be  "delivered".  This  will  be  the  final  promotion  in  a given 
hierarchy.  The  system  will  then  either  be  ready  for  installation  in  the  final 
target  environment,  or  it  will  become  a subsystem  in  a higher-level  promotion 
hierarchy . 
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Figure  8.2-8.  Promotion  Hierarchy  After  Initial  Builds:  This  is  how  the  promotion  hierarchy  for  System  "A"  looks 
after  builds  have  occurred  for  the  E and  C subsystems.  Note  that  users  with  no  more  inputs  to  a 
subsystem  have  been  removed  from  the  hierarchy. 

8. 2. 5. 3. 5 BASELINE 

Until  the  baseline  function  is  performed  all  modules  and  subsystems  promoted 
into  a subsystem's  collection  pool  are  in  a pending  state.  The  baseline 
function  takes  them  out  of  the  collection  pool  and  makes  them  a permanent  part 
of  the  subsystem.  This  involves  updates  to  the  subsystem's  descriptor  and 
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Figure  8.2-9.  Promotion  Hierarchy  During  System  Integration:  This  is  how  the  promotion  hierarchy  looks  during 
system  integration.  The  subsystem  nodes  have  been  deleted.  Only  users  who  need  to  make  updates 
to  the  integrated  system  are  in  the  hierarchy. 

history  files  and  possibly  also  updates  to  the  subsystem's  libraries.  The 
baseline  process  does  not  necessarily  make  copies  of  the  baselined  items  In 
many  cases  (especially  when  baselining  a promoted  subsystem),  updating  the 
descriptor  files  is  all  that  is  necessary.  The  baseline  process  may  also  copy 
only  certain  elements  of  a module  (e.g.,  source,  but  not  object).  Whether  to 
copy  and  what  to  copy  are  options  selectable  by  the  subsystem's  coordinator. 
Even  though  the  promotion  function  checks  for  proper  configuration  management 
authorization,  the  baseline  function  checks  again  and  then  provides  the 
appropriate  feedback  to  the  Configuration  Management  function. 

8. 2. 5. 3. 6 SUBSYSTEM  INTEGRATION 

After  the  baseline  function  has  been  performed  on  a subsystem  it  may  not  be 
immediately  useable.  For  example,  if  only  source  is  baselined,  modules  must 
be  recompiled  before  subsystem  testing  can  take  place.  The  Subsystem 
Integration  function  takes  care  of  any  translations  or  re-formatting  which 
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must  be  done  to  the  contents  of  the  subsystem's  libraries  to  make  the 
subsystem  ready  for  its  users. 

Subsystem  Integration  will  check  dependencies  and  (based  on  local  options) 
either  flag  or  automatically  re-translate  modules  which  are  dependent  on 
modules  which  have  been  changed  since  the  last  integration.  Depending  on  the 
content  of  the  External  Dependencies  portion  of  the  subsystem's  Descriptor 
File  and  on  options  set  by  the  subsystem  coordinator.  Subsystem  Integration 
can  use  modules  from  other  subsystems  to  resolve  references  and  produce  a 
useable  subsystem. 

8. 2. 5. 3. 7 TEMPORARY  INTEGRATION 

Temporary  Integration  can  be  done  by  any  user  wishing  to  create  a temporary 
copy  of  a subsystem  for  early  testing  or  consistency— checking . Temporary 
Integration  differs  from  subsystem  integration  in  that  it  operates  outside  of 
configuration  control: 

1.  it  does  not  require  any  Configuration  Management  authorization, 

2.  it  does  not  require  a baselined  subsystem, 

3.  it  does  not  update  any  descriptor  or  history  files, 

A.  it  does  not  make  copies  of  any  of  the  input  libraries. 


The  user  can  select  any  subsystems  or  user  libraries  to  use  as  input,  select 
or  reject  the  subsystems'  collection  pools  as  input  sources,  and  choose  what 
kind  of  dependency-checking  and  re-translations  to  perform.  Depending  on  the 
options  selected,  temporary  integration  can  be  used  for  a wide  range  of 
tasks.  For  example,  temporary  integration  can  be  used  to  create  a prototype 
version  of  a subsystem  constructed  from  existing  subsystems  and  user 
libraries.  It  can  also  be  used  to  verify  that  the  contents  of  a collection 
pool  will  be  consistent  during  system  integration  before  the  permanent 
integration  process  is  executed. 
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8. 2. 5. 3. 8 SUBSYSTEM  CONTENTS 


Each  subsystem  in  a promotion  hierarchy  consists  of  four  major  elements:  a 

descriptor  file,  a history  file,  a set  of  libraries,  and  a collection  pool 
(see  Figure  8.2-10).  The  following  paragraphs  further  explain  the  contents  of 
each  of  these  elements. 

8. 2. 5. 3. 8.1  DESCRIPTOR  FILE 

The  Descriptor  File  contains  two  kinds  of  data.  The  module  descriptor  data 
provides  information  necessary  to  retrieve,  translate,  and  integrate  the 
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Figure  8.2-10.  Contents  of  a Subsystem 
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modules  in  the  subsystem.  For  each  module,  this  data  includes  a list  of  the 
elements  (source,  object,  design,  data)  which  make  up  the  module,  pointers  to 
the  libraries  in  which  the  elements  reside,  control  data  for  the  translators 
(compilers,  formatters)  which  operate  on  the  module's  elements,  and  a 
cross-reference  of  dependencies  between  the  module  and  other  modules  (for  use 
in  integration  processing). 

The  external  dependency  data  in  the  Descriptor  File  describes  how  to  find 
external  modules  (system  macros,  common  subroutines)  which  are  needed  by 
modules  in  the  subsystem.  This  data  includes  a li3t  of  external  modules 
needed  and  pointers  to  the  external  libraries  which  contain  those  modules. 


8. 2. 5. 3. 8. 2  LIBRARIES 

The  libraries  in  a subsystem  are  the  files  which  contain  the  various  elements 
which  make  up  the  subsystem's  modules.  A library  is  not  any  particular  type 
of  file.  It  may  be  a single  physical  file,  a logically— related  collection  of 
physical  files,  or  a logically— related  subset  of  a physical  file. 


8. 2. 5. 3. 8. 3 HISTORY  FILE 

The  History  File  contains  a complete  record  of  all  changes  to  a subsystem  from 
some  pre-determined  base  version  to  the  present.  This  includes  change 
instrument  numbers,  source  lines  changed  in  a module,  modules  re-translated 
during  integration,  and  subsystems  integrated  into  the  subject  subsystem. 

8 . 2 . 5 . 3 . 8 . 4 COLLECTION  POOL 

The  Collection  Pool  contains  updates  to  the  subsystem  which  have  been 
promoted,  but  which  have  not  yet  been  baselined.  These  updates  include  at 
least  the  source  element  of  an  updated  module,  but  may  also  include  any  (or 
all)  of  the  other  elements.  Updates  to  module  descriptor  data  are  also 
promoted  to  the  collection  pool  to  await  baselining. 
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8. 2. 5. 3. 9 REUSABLE  COMPONENTS 


The  developers  and  maintainers  of  reusable  software  components  will  use  the 
same  build  and  integration  tools  as  other  users  of  the  SSE.  Special  functions 
are  provided  to  notify  users  of  a reusable  component  of  changes  to  the 
component  in  the  master  component  libraries.  Tools  for  the  retrieval  and 
tailoring  of  components  are  discussed  in  "Design  and  Code  Generation". 

8. 2. 6.0  TESTING  AND  ANALYSIS 

Testing  is  the  examination  of  program  execution  behavior.  Testing  of  the  Space 
Station  software  will  be  very  important  because  of  its  life/mission  critical 
nature.  Facilities  must  be  provided  in  the  SDE  for  testing  because  of  the 
inability  to  observe  the  software  in  actual  use  in  a safe  environment  (i.e.  on 
the  ground).  These  test  facilities  should  include  a variety  of  tools  that  will 
support  cost  effective  testing  of  the  SSDMS,  application  software,  and  payload 
software . 

There  are  five  steps  of  a test  process  (see  Figure  8.2-11).  They  are 

1.  Test  Planning 

2.  Test  Design  and  Development 

3.  Test  Execution  and  Simulation 

4.  Data  Reduction  and  Analysis 

5.  Test  Report  Generation 

The  tools  and  capabilities  described  in  this  section  represent  the  full 
spectrum  of  test  facilities  for  the  project.  Subsets  may  be  defined  and  used 
to  support  various  levels  such  as  unit  testing,  performance  testing,  and 
independent  verification  and  validation. 

8.2.6. 1 PLANNING 

This  involves  gathering  all  data  concerning  the  software  to  be  tested, 
analyzing  it,  and  deciding  what  tests  need  to  be  performed.  The  list  of  tests 
to  be  performed  and  rationale  for  the  tests  are  put  into  a test  plan.  The 
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Figure  8.2-11.  Steps  in  the  Typical  Testing  Process 


8-37 


rationale  is  an  explanation  for  why  the  specified  tests  were  chosen.  Possible 
explanations  are  'to  test  a specific  requirement'  or  to  'test  a high 
complexity  (high  risk)  section  of  the  code'.  The  following  is  a list  of 
possible  static  analysis  tools  that  could  be  used  to  facilitate  the  planning 
of  tests. 

1.  Logic  Flow  Graph  Generators 

A tool  of  this  type  would  create  a summary  of  the  control  flow  of  the  program 
to  be  tested.  One  use  of  this  information  is  to  plan  test  coverage. 

2.  Data  Flow  Graph  Generators 

A tool  of  this  type  would  create  a summary  of  the  flow  of  data  in  the  program 
to  be  tested.  One  use  of  this  information  is  to  test  for  errors  in  the  set/use 
of  variables. 

3.  Complexity  Measuring  Tools 

A tool  of  this  type  would  create  measures  of  the  complexity  of  the  program  to 
be  tested.  This  information  is  useful  in  identifying  high  risk  areas  of  the 
code.  These  areas  would  require  a higher  test  coverage. 

4.  Interface  analyzers 

A tool  of  this  type  would  create  a summary  of  interface  information  of  the  set 
of  modules  being  tested.  This  information  would  be  useful  for  subsystem 
integration. 

8. 2. 6. 2 DESIGN  AND  DEVELOPMENT 

This  involves  creating  test  procedures  and  a test  script  that  will  accomplish 
all  the  tests  and  testing  goals  identified  in  the  test  plan.  Test  procedures 
will  outline  the  strategy  for  accomplishing  the  tests  and  the  test  script  will 
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contain  all  necessary  details.  The  test  script  will  be  directly  executed  (i.e. 
equivalent  to  code)  while  the  test  procedure  is  the  design  (i.e.  equivalent  to 
program  design). 


Many  of  the  facilities  necessary  to  support  test  case  design  and  development 
are  the  same  tools  necessary  to  support  program  design  and  development  (see 
"Design  and  Code  Generation").  These  are 

1.  High  level  languages  to  facilitate  the  design  and  development  of  test 
cases.  This  language(s)  will  support  design  of  the  test  procedures  and  the 
development  of  the  test  script. 

2.  Syntax  Directed  Editor 

This  type  of  editor  would  directly  support  the  development  of  test  cases  in 
the  high  level  test  language  by  providing  skeletons  of  all  structures  in  the 
language . 

3.  Test  Script  Static  Analysis  Aids 

Tools  of  this  type  will  analyze  the  test  script  for  potential  development 
errors.  Some  examples  of  potential  errors  are 

a.  Incorrect  use  of  the  simulator  capabilities 

b.  Incorrect  use  of  the  Space  Station  system  capabilities 

c.  Incorrect  references  to  program  variables  and  locations 

d.  Incorrect  test  facility  or  simulator  configuration 

Detecting  these  errors  in  test  cases  before  the  tests  are  executed  will  help 
eliminate  may  wasted  test  executions  (which  may  be  expensive)  and  will  help 
eliminate  analysis  of  errors  that  were  due  to  an  incorrect  test  script. 

4.  Test  Libraries  and  Reusability 


To  promote  Reusability  in  test  cases  there  should  be  tools  to  encourage  and 


facilitate  the  use  of  test  case  components.  The  tools  will  of  the  same  ones 
used  for  software  development  (see  "Design  and  Code  Generation").  These  tools 
should  support  the  maintenance  and  use  of  libraries  of  test  case  components. 

5.  Stub/Driver  Generator 

A tool  of  this  type  would  generate  skeleton  stubs  and  drivers  necessary  for 
execution  of  the  program  being  tested.  This  would  need  to  be  done,  for 
example,  when  the  module  calls  another  procedure  that  has  not  yet  been  coded. 

6.  Test  Data  Generators 

A tool  of  this  type  would  generate  test  data  to  be  used  to  test  the  program. 
The  test  data  will  be  generated  to  accomplish  a specific  test  goal  such  as 
forcing  execution  down  a specific  path  or  testing  boundary  conditions. 


8. 2. 6. 3 EXECUTION  AND  SIMULATION 

This  involves  applying  the  test  scripts  to  the  software  being  tested  and 
creating  a set  of  test  results.  To  support  the  actual  execution  of  the  test 
cases  a dynamic  test  facility  must  provide  the  following 

1.  Diagnostic  capabilities 

The  required  capabilities  vary  from  unit  test  to  system  testing.  Unit  testing 
will  require  more  detailed  diagnostics  such  as  traces,  stop  on  address 
compare,  variable  altering,  variable  snapping,  etc.  These  diagnostic 
capabilities  allow  the  programmer  to  effectively  test  and  debug  his  software 
module.  Since  it  is  much  cheaper  to  catch  errors  in  the  unit  testing  process 
than  it  to  catch  the  same  errors  later  in  the  testing  process,  it  is  important 
to  provide  these  detailed  diagnostics  to  encourage  and  facilitate  early  error 
detection.  System  testing  will  not  require  diagnostic  capabilities  as 
detailed  as  unit  testing  will. 
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2.  Performance  monitors 


These  are  necessary  to  monitor  performance  characteristics  of  the  system  such 
as  CPU  utilization,  timing/synchronization,  and  bus  traffic  throughput. 

3.  Simulation 

To  model  unavailable  parts  of  the  system  and  environmental  effects,  a set  of 
simulation  models  must  be  provided.  The  amount  and  fidelity  required  will 
vary  from  unit  testing  to  system  testing  with  system  testing  having  the  most 
stringent  requirements . High  fidelity  simulation  resources  will  be  limited  and 
a simulator  scheduling  facility  will  be  provided  to  optimize  use  of  these 
resources . 

4.  Data  Logging 

Sampling  of  many  different  items  will  occur  during  test  case  executions. 

Often,  much  of  this  data  will  need  to  be  analyzed  after  the  tests.  Adequate 
facilities  must  be  provided  for  short  and  long  term  storage  of  this  data. 

8. 2. 6. 4 DATA  REDUCTION  AND  ANALYSIS 

This  involves  formatting  and  summarizing  the  test  results  obtained  from  the 
Test  Execution  and  analyzing  the  results  to  determine  success/failure  of  the 
software  to  pass  the  tests  applied.  The  data  logged  during  the  test  execution 
should  be  reduced,  summarized  and  formatted  into  two  different  possible 
formats.  The  first  format  will  be  a report  suitable  for  human  viewing  and 
analysis.  This  would  include  a variety  of  graphical  and  text  formats.  The 
second  format  would  be  one  that  is  suitable  for  input  to  a program  to  perform 
some  automated  analysis. 

8. 2. 6. 5 REPORT  GENERATION 


This  involves  assembling  all  work  products  generated  during  previous  steps  of 
the  test  process  into  a report.  The  format  and  the  content  of  the  test 
reports  will  vary  across  different  test  groups.  They  may  contain  any  of  the 
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possible  work  products  generated  during  testing.  These  include  the  test  plan, 
test  design,  test  procedures,  test  execution  configuration,  analysis  results, 
and  problems  and/or  anomalies  found.  These  work  products  will  be 
automatically  formatted  into  a preliminary  version  of  the  test  report.  Then 
the  report  can  be  completed  manually. 

8 . 2 . 7 . 0  DOCUMENTATION 


The  documentation  function  will  provide  online  documentation  facilities  to 
create  a minimum  paper  environment  with  hard  copying  capability.  This 
function  will  be  used  for  viewing  as  well  as  creating  the  online  documents. 
There  will  be  a capability  to  assign  access  levels  for  security  of  nonpublic 
documents.  Examples  of  document  types  are:  requirements , user's  guides, 

instruction  manuals,  test  specifications,  program  test  reports,  software  build 
reports,  status  reports,  and  working  papers. 

Working  papers  are  lost,  historically,  in  most  long-lived  projects  as  the 
designers  move  on  to  newer  tasks.  The  documentation  capabilities  will  support 
the  archiving  of  background  information,  such  as  design  rationale  and 
justification,  etc. 

8.2.7. 1 SUBFUNCTIONS 

8.2.7. 1.1  PROVIDE  ONLINE  DOCUMENTATION  FACILITIES 

Online  documentation  facilities  must  be  provided  to  all  SSE  users.  This 
includes  the  ability  to  create  and  maintain  document  source  online  and  the 
ability  to  access  formatted  documents  online.  Multiple  versions  of  documents 
will  be  maintained  to  reflect  the  multiple  versions  of  software  being  used  and 

developed  at  a time.  The  users  will  be  able  to  obtain  hard  copies  of  selected 
documents . 

8.2.7. 1.2  PROVIDE  MEANS  TO  "REDLINE"  DOCUMENTS  ONLINE 

With  electronic  transmissions  of  review  documents,  a means  will  be  provided  to 
facilitate  "redlining"  a document  to  indicate  desired  changes. 
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8. 2. 7. 1.3  PROVIDE  CROSS  REFERENCE  CAPABILITY  WITH  ONLINE  RETRIEVAL 


A means  for  users  to  cross  reference  topics  between  the  books  and  volumes, 
such  as  a trace  from  requirements  to  a users  guide  must  be  provided.  It  will 
enable  users  to  relate  the  software  development  phases  to  categories  of 
documents  to  ease  the  documenting  and  retrieval  tasks.  An  information 
retrieval  system  would  provide  an  efficient  means  to  locate  information  by 
subject  or  keywords. 

8.2.7. 1.4  PROVIDE  INTEGRATED  TEXT/GRAPHICS  SUPPORT 

This  function  will  provide  integrated  document  text  and  graphics  support  with 
a means  for  identifying  revision  levels. 

8. 2. 7. 1.5  CONFIGURATION  MANAGEMENT 


An  interface  the  the  configuration  control  and  management  support  system  (see 
"Configuration  Control  and  Management  Support")  system  must  be  provided  to 
support  configuration  of  documents. 

8. 2. 7. 2 CHARACTERISTICS 

The  documentation  function  will  encourage  thorough  documentation  by  being  easy 
to  learn  and  use. 

Some  uses  for  the  tools,  e.g.,  maintaining  working  papers,  do  not  require 
configuration  control  and  users  should  be  able  to  perform  these  tasks 
exclusive  of  the  control  functions. 

8 . 2 . 8 . 0 COMMUNICATION 

The  communication  function  will  provide  the  means  to  make  the  SSE  appear  as  a 
single  facility  to  each  user,  regardless  of  site  location.  It  will  enable  a 
user  to  send  and  receive  data,  e.g.,  documents,  messages,  or  software  to  other 
users  or  functions  of  the  SSE.  This  function  will  field  requests  from  other 
functions  to  transfer  data  between  functions  and  to  users. 
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8.2.8. 1  SUBFUNCTIONS 


8. 2. 8. 1.1  MESSAGES  BETWEEN  USERS 

1.  Facilitate  inter  and  intra  user  group  communication 

User  groups  will  be  conducting  reviews  of  all  types  (e.g.,  requirements 
review,  design/code  review,  test  specif ication/procedure  review).  The  reviews 
require  communications  between  the  groups  for  the  scheduling  of  reviews,  and 
resolution  of  review  comments, 

2.  Provide  means  for  users  to  schedule  resources 

Users  will  be  able  to  communicate  between  sites  to  coordinate  resources  for 
things  such  as  integrated  testing. 

8.2.8. 1.2  DATA  TRANSFER  BETWEEN  USERS  OR  SSE  FUNCTIONS 

1.  Support  transfer  of  software  between  SSE  and  contractors 

This  function  of  the  SSE  will  provide  a method  for  both  simulator  models  and 
application  software  to  be  transmitted  between  the  SSE  and  the  contractor 
sites  for  review  (source)  or  execution  (modules). 

2.  Interface  with  TMIS 

Many  of  the  SSE  functions  will  send  or  receive  data  (e.g.,  plans,  schedules, 
documents,  status)  to  the  TMIS  for  Space  Station  program  management.  This 
function  will  provide  the  interface  with  the  TMIS  system. 
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3.  Provide  interface  to  all  SSE  functions 


All  other  SSE  functions  use  this  function  to  communicate  status,  schedules, 
product  dependencies,  configuration  control  instrument  status,  and  to  transmit 
program  software  products  with  other  functions. 

4.  Provide  means  for  document  transfer 

Users  will  be  able  to  transfer  documents  between  sites. 

5.  Provide  interface  to  reusable  software  library 

To  promote  software  commonality,  it  is  envisioned  that  a reusable  software 
library  will  be  a part  of  the  SSE.  Users  will  be  able  to  send  and  retrieve 
elements  to  and  from  this  library. 

8. 2. 8. 2 CHARACTERISTICS 

For  the  other  SSE  functions  to  be  used  effectively,  communications  between 
these  functions  and  the  users  is  essential.  Therefore,  the  communications 
function  must  operate  in  a straight-forward  and  easy— to— use  manner  to 
encourage  such  use. 

8. 2. 9.0  RECONFIGURATION 

The  software  on  the  Space  Station  will  be  required  to  interface  with  a vast 
number  of  hardware  components  (e.g.  IMUs,  rate  gyros,  etc.).  During  the  life 
time  of  the  station,  it  will  be  necessary  to  integrate,  test,  operate,  and 
replace  hardware  components.  Each  component  has  specific  characteri sties 
which  must  be  provided  for  within  the  software.  Reconfiguration  data  is  that 
set  of  data  values  required  to  tailor  the  application  software  and  UIL 
interface  environments  to  be  compatible  with  a specific  hardware 
configuration.  The  process  of  managing  the  reconf iguration  data  and 
incorporating  updates  into  the  target  system  (e.g.  onboard  DMS,  integration 
test  sets)  is  called  reconf iguration.  The  SSE  must  support  this  activity. 
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8.2.9. 1 SUBFUNCTIONS 

8. 2. 9. 1.1  DATA  COLLECTION  AND  MAINTENANCE 

Data  pertaining  to  each  hardware  unit  which  will  interface  with  the 
application  software  must  be  available  in  the  SSE.  Data  representative  of 
actual  flight  hardware  components  (e.g.  IMUs,  Rate  Gyros)  will  come  from  the 
TMIS.  Other  data,  for  example  test  unique  data,  will  originate  in  the  SSE. 
This  data  will  be  maintained  in  a data  base  and  interfaces  must  be  provided 
for  the  user  to  update  and  review  the  data. 

8. 2. 9. 1.2  DATA  SELECTION 

The  data  base  will  contain  data  for  many  hardware  components,  not  all  of  which 
will  coexist  in  a single  configuration.  By  identifying  a subset  which  could 
coexist,  a specific  configuration  is  defined.  The  ability  to  define 
configurations  and  subsets  of  configurations  will  be  provided  through  the  use 
of  interactive  menues  and  commands.  The  ability  to  to  define  and  store 
configurations  will  also  be  provided. 

8.2.9. 1.3  DELIVERY 

Data  from  the  data  base  will  be  extracted  and  delivered  to  target 
environments.  (See  "Hardware  Interface".)  Thre  target  operating  system  will 
then  use  the  data  base  to  provide  the  hardware  interface  services  for  both  the 
application  and  the  user  interface  environments. 

8 . 2 . 9 . 2 CHARACTERISTICS 

An  interface  with  the  configuration  control  system  will  be  provided  to  support 
configuration  control  of  data  representing  onboard  hardware  and  some  of  the 
testing  configurations.  The  ability  will  also  exist  for  users  to  define  data 
and  configurations  for  testing  without  requiring  configuration  control.  After 
IOC,  a representation  of  the  actual  onboard  configuration,  as  well  as  test  and 
development  configurations,  will  always  be  maintained  within  the  system. 
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8.2.10.0  ON-BOARD  DATA  MANAGEMENT  SYSTEM  (DMS) 


The  On-board  Data  Management  System  will  consist  of  the  software  and  hardware 
to  support  crew  control  of  the  Space  Station  (SS)  structure  and  other  SS 
subsystems.  These  systems  include  a set  of  "core  elements"  such  as 
housekeeping  data  (e.g.,  time),  -a  data  storage  system,  a Crew  Interface 
system,  a network  for  support  of  a distributed  processing  system,  and  an 
operating  system  which  supports  many  core  and  payload  systems.  The  software 
and  hardware  of  the  DMS  will  be  configured  into  a network  of  Subsystem  Data 
Processors  (SDP's),  Network  Interface  Units  (NIU's),  and  data  buses  connecting 
sensors/ef f ectors  into  a network(s).  The  SSE  will  provide  the  environment  for 
development  of  the  DMS.  Once  developed,  the  DMS  will  be  made  available  in  the 
SSE  for  application  software/hardware  development  and  verification. 

8.2.10.1  SUBFUNCTIONS 

8.2.10.1.1  SOFTWARE  SYSTEMS 

8.2.10.1.1.1  NETWORK  OPERATING  SYSTEM  (NOS) 

The  Network  Operating  System  will  support  process/data  distribution  and  data 
base  interfaces  as  a service  to  the  application  development.  Within  the  SSE, 
the  NOS  will  provide  applications  with  the  capability  to  configure  software 
into  a network  compatible  to  the  on-board  system  for  development  and  test. 

8.2.10.1.1.2  DISPLAY  GENERATION/SUPPORT 

The  principal  interface  of  the  SS  crew  will  be  the  display  unit  (Multipurpose 
Application  Console  (or  MPAC)).  The  DMS  display  generation/support  software 
will  be  provided  in  the  SSE  to  support  the  generation  and  test  of  displays. 

The  display  generation  function  will  provide  the  options  for  diagnostics 
sufficient  to  guide  the  development  and  verification  of  display (s). 
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8.2.10.1.1.3  REAL  TIME  OPERATING  SYSTEM  (RTOS) 


The  Real  Time  Operating  System  in  conjunction  with  the  NOS  provides  for  a 
complete  application  support  environment. 

8.2.10.1.1.4  DATA  BASE  MANAGEMENT  SYSTEM  (DBMS) 

The  Data  Base  Management  System  will  provide  the  data  storage  and  retrieval 
necessary  (in  conjunction  with  the  NOS)  to  support  application  archiveing  of 
data  for  trend  analysis  or  for  transmission  via  the  Tracking  Data  Relay 
Satelite  (TDRS)  or  other  Radio  Freqrency  (RF)  means  to  the  ground. 

8.2.10.1.1.5  HARDWARE  INTERFACE 

The  DMS  must  provide  the  application  software  and  user  interface  environments 
with  an  interface  to  the  hardware  sensors  and  effectors  with  which  they  will 
be  communicating.  This  service  is  necessary  to  isolate  the  application  and 
user  interface  environments  from  changes  in  hardware  configurations.  This 
will  be  accomplished  by  maintaining  a data  base  in  the  target  environments 
which  contains  a representation  of  the  current  configuration  and  data  unique 
to  each  hardware  component  present.  The  data  in  the  data  base  will  be  used  by 
the  DMS  to  provide  addressing,  scaling  and  formating  of  hardware  data.  Data 
base  maintenance  will  be  dictated  by  changes  in  the  configuration.  The  DMS 
will  provide  an  interface  for  users  to  indicate  modifications  to  the  current 
configuration  (e.g.  replacing  one  component  with  another).  When  new  hardware 
is  delivered  to  the  station,  associated  data  will  be  delivered  from  the  SSE 
and  will  be  processed  and  stored  in  the  data  base  by  the  DMS.  An  interface 
will  be  provided  to  enter  hardware  components  that  are  being  discarded  so  that 
the  corresponding  data  in  the  data  base  will  be  deleted. 

8.2.10.1.2  DMS  HARDWARE  SYSTEMS 

The  DMS  hardware  must  be  capable  of  supporting  the  functional  requirements  as 
required  by  the  on-board  systems  (both  core  systems  and  application  systems). 
It  is  assumed  that  the  On-Board  software  functions  will  be  a distributed 
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system  sharing  data  over  a data  link  or  "BUS".  The  DMS/SSE  will  provide  the 
hardware  necessary  for  application  development  and  test. 

8.2.10.1.2.1  STANDARD  DATA  PROCESSOR  (SDP) 

The  primary  application  processor  will  be  a Standard  Data  Processor.  The  SSE 
will  provide  one  or  more  SDP's  for  execution  of  applications  in  the  SS  target 
language . 


8.2.10.1.2.2  NETWORK  INTERFACE  UNIT  (NIU) 

The  Network  Interface  Unit  will  be  the  standard  hardware  unit  which  will 
connect  all  SDP's  to  the  network  of  SDP's  and  sensors/eff ectors . The  SSE  will 
provide  for  the  NIU's  just  as  it  will  with  the  SDP's  above. 

8.2.10.1.2.3  NETWORK  BUS 

The  processor  network  will  be  interconnected  with  a bu3  or  ring.  In  the  SSE, 
the  bus(es)  necessary  for  the  formation  of  a net  for  application  testing  will 
be  provided.  The  make  up  of  this  bus  and  the  network  as  a whole  must  be 
transparent  to  the  user. 

8.2.10.1.2.4  MASS  STORAGE 


The  On-Board  systems  require  a mass  storage  device(s)  for  software  systems 
such  as  the  NOS,  RTOS,  Display  generation  and  other  software  elements  in 
support  of  the  SS  and  to  support  data  archival  for  trend  analysis  or  for 
retransmission  to  ground  systems  when  RF  transmission  is  more  readily 
available.  Mass  storage  sufficient  for  application  development  will  be 
provided  in  the  SSE. 
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8.2.10.1.3  DMS/ SSE  SOFTWARE  TOOLS 


There  is  a set  of  software  programs  which  support  any  software  development 
which  is  normally  thought  of  as  being  resident  in  a host  environment  such  as 
in  the  SSE.  Because  of  the  nature  of  the  Space  Station,  a subset  of 
development  tools  must  be  resident  on-board.  The  Display  Generation/Support 
could  be  considered  as  in  this  categorary.  Other  tools  include  compilers, 
linkers,  debug,  diagnostics,  deloggers.  This  is  not  a complete  list  of  such 
tools.  The  allocation  of  these  tools  to  DMS  on-board  or  SSE  will  be 
determined.  Both  the  on-Board  DMS  and  the  SSE  must  support  the  upload  and 
download  of  programs  and  data.  In  the  life  time  of  the  Space  Station,  a large 
range  of  software  and  hardware  and  software  upgrades  must  be  supported. 

8.2.10.2  DMS  CHARACTERISTICS 

The  Data  Management  System  must  be  flexible  to  support  an  environment  where 
the  nature  of  the  support  is  critical  (involve  life  support  systems,  SS 
attitude  control,  etc.)  to  very  simple  functions  such  as  providing  time  and 
other  parameters  to  payload  customers.  Some  of  the  critical  systems  such  as 
GN&C  must  not  only  be  redundant  but  must  be  restartable  in  case  of  a bus,  SDP, 
or  other  failure  situation  in  which  the  critical  functions  are  terminated.  The 
following  are  other  generic  requirements  of  the  DMS. 

• Software/Hardware  interfaces  must  be  well  definded,  simple  and  stable. 

• The  user  (crew)  interfaces  must  be  easy  to  use  and  provide  a step  by  step 
method  (e.g.  menus)  for  the  inexperienced  user  and  a short  cut  for 
experienced  user. 

• All  crew  actions  must  be  logged  on-board  or  ground  for  historical 
processing  in  the  SSE. 

• Where  possible,  routine  actions  must  be  automated  to  support  a mantended 
environment  as  well  as  allowing  the  crew  to  pursue  other  tasks.  This 
automation  must  also  be  provided  with  crew  override. 

• On-board  to  ground  and  ground  to  on-board  communications  must  be  minimized 
to  conserve  RF  bandwidth. 
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8.3  SYSTEM  TEST,  INTEGRATION  & VERIFICATION  (STIV) 


Previous  sections  of  this  report  have  addressed  the  various  aspects  of  the 
SSDS  definition  process.  This  section  will  discuss  concepts  associated  with 
the  major  steps  in  the  STIV  process  that  can  influence  key  design  and 
programmatic  decisions. 

Task  2 (options  development)  identified  and  characterized  several  options 
available  in  the  STIV  process  that  provide  the  opportunity  for  meaningful  cost 
and  schedule  savings  throughout  the  evolutionary  lifetime  of  the  SSDS.  These 
options  are  being  assessed  as  part  of  a major  trade  study  (Task  3)  to  define 
preferred  techniques,  methodologies,  facilities  and  resources  required  for 
STIV. 

8.3.1  Test 

SSDS  testing  definition  and  policies  planning  will  be  an  integration  of  Level 
SE&I  direction  and  the  preferred  options  identified  in  associated  trade 
studies.  This  integration  will  be  structured  around  the  scheduled 
availabilities  of  SSDS  elements.  Cost  will  be  a primary  driver  in  structuring 
the  test  program. 

Early  decisions  are  required  in  several  areas  (as  discussed  later)  to  identify 
and  schedule  long  lead  time  facilities  and  resources  for  integration  with 
fiscal  year  funding  contraints  into  DTC/LCC  planning. 

Hardware  should  be  designed  to  maximize  the  use  of  commercially  available  test 
equipment  for  both  acceptance  and  qualification  tests. 


8. 3. 1.1  Development  Tests 

Development  tests  are  engineering  evaluation  tests  to  minimize  technical  risks 
and  to  provide  proof  of  design  concepts.  They  may  include  material  selection, 
failure  modes  and  effects,  design/operating  tolerances,  etc. 
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For  those  elements  judged  to  require  engineering  development  testing,  long 
lead  time  requirements  must  be  identified  very  early  in  the  program.  Hardware 
development  will  utilize  NASA  testbeds,  or  similar  facilities  at  the 
developing  contractors  location.  For  software,  the  long  lead  items  required 
first  are  those  development  tools  for  the  Software  Support  Environment  (SSE). 
These  include  the  Higher  Order  Programming  Languages,  Support  Software, 
Operating  Systems,  Users  Interface  Language,  and  the  Network  Operating  System. 


8. 3. 1.2  Qualification  Tests 

Qualification  testing,  from  both  the  functional  requirements  and  the 
environmental  requirements  viewpoint,  can  be  one  of  the  most  costly  items  of  a 
large  space  program.  The  protoflight  concept  must  be  considered  for 
application  to  all  elements  of  the  SSDS  system  to  reduce  costs. 

The  most  cost-effective  method  of  utilizing  qualification  units  for  flight 
must  be  determined  in  each  case.  The  protoflight  concept  can  be  implemented 
by:  increased  design  margins  to  arrive  at  a "no-test"  or  "qualification  by 

analysis"  situation;  the  use  of  additional  inspection  techniques  after  the 
qualification  test,  such  as  open  box  inspections  or  X— ray  examinations; 
refurbishment  or  replacement  of  critical  components  in  the  assembly.  Other 
cost  avoidance  techniques  are:  deferred  module  testing,  i.e.,  qualification  at 
the  highest  assembly  level  practical;  selective  environmental  qualification 
(all  assemblies  need  not  be  qualified  to  the  3ame  level  depending  on  location, 
shielding,  etc.);  modified  qualification  levels,  considering  the  criticality 
of  the  assembly.  These  techniques  will  be  examined  early  in  the  design  phase 
of  all  hardware  assemblies  requiring  qualification  testing. 


In  parallel  with  the  development  of  the  SSDS  system  definition.  Phase  B Space 
Station  Systems  Engineering  will  be  defining  the  environmental  levels  for  the 
various  hardware  applications.  Qualification  testing  planning  will  then  move 
into  a more  detailed  phase  with  early  emphasis  on  accommodating  the 
protoflight  concept.  Qualification  testing  should  utilize  acceptance  test 
software  whereever  possible  to  minimize  costs. 
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8.3. 1.3  System  Tests 


The  anticipated  SSDS  testing  will  follow  a sequence  of  ground  segment 
activation  and  checkout,  integration  and  test  of  space  segment  elements 
assigned  to  modules/launch  packages,  and  integration  of  those  elements  within 
the  module.  Some  limited  end-to-end  testing  possibly  utilizing  TDRSS  may 
occur  during  pre-launch  integration  efforts;  final  testing  will  occur  during 
on-orbit  assembly/activation  of  station  and  platform(s). 

Early  planning  will  incorporate  NASA  SE&I  defined  policies  and  preferred  test 
options  identified  during  trade  activities.  Key  outputs  of  this  planning  will 
be : 

a.  definition  of  simulators  and  the  degree  of  fidelity  required. 

b.  definition  of  SDE  support  requirements . 

c.  definition  of  te3t  sequence,  (to  be  coordinated  with 
development/production  scheduling) . 

8.3.2  Integration 

The  methods  and  degree  of,  both  hardware/software  integration,  will  be 
identified  initially  by  trade  studies  early  in  the  program  and  refined  as  the 
system  matures.  Both  hardware  and  software  will  be  under  development  by 
several  different  contractors  at  several  different  locations,  and  this  will 
occur  over  a significant  span  of  time.  Therefore,  a well  conceived 
integration  plan  must  be  available  early  in  the  program  to  identify  GSE, 
facilities,  and  other  resources,  including  provisions  for  growth,  so  that 
integration  tasks  and  schedules  are  not  impacted  by  lack  of  definition  or 
appropriate  support. 

The  following  sections  discuss  selected  integration  activities  peculiar  to 
hardware  and  to  software. 
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8. 3. 2.1  Hardware  Integration 


Integration  of  the  hardware  components  of  the  SSDS/SSIS  will  depend  on  several 
factors.  The  protoflight  concept  dictates  that  all  hardware,  in  so  far  as 
possible,  will  be  designed  and  built  with  the  end  purpose  of  being  usable  as 
flight  hardware.  This  concept  implies  that  the  hardware  will  not  be 
continuously  available  in  a development/integration  facility,  but  rather,  may 
cycle  through  such  a facility  as  it  progresses  to  a launch  package  onboard  the 
NSTS.  Obviously,  enough  flight-type  hardware  mu3t  be  available  at  some  point 
in  the  development  phase  to  prove  out  critical  issues  such  as  data  rates, 
processing  throughput,  standardized  payload  interfaces,  etc. 

A policy  for  the  degree  of  standardization/commonality  of  the  processors  for 
Bus  Interface  Units,  Common  Data  Processors,  etc.  must  be  established  as  this 
will  have  an  influence  on  the  integration  tasks  by  determining  how  many  units 
must  cycle  through  the  integration  process. 

Along  with  standardization/commonality , elements  should  be  designed  such  that 
commercially  available  test  equipment  can  be  used.  The  "golden  box" 
laboratory  test  approach  should  be  used  where  practical  to  reduce  GSE  and 
formal  test  procedure  requirements . This  is  justified  for  small  production 
quantity  elements.  However  for  elements  to  be  produced  in  quantities  and 
whose  interfacing  inputs  are  likely  to  have  significant  excursions,  then  a 
more  rigorous  text  approach  will  be  required.  This  is  based  on  the  premise 
that  for  more  applications/users,  more  design  margin  will  be  required. 

The  prelaunch  readiness  testing  at  KSC  will  be  limited  to  that  necessary  to 
confirm  no  degradation  from  shipping,  depending  on  integration  strategies 
implemented.  Each  package  to  be  delivered  on  orbit  will  receive  a functional 
checkout  before  installation  in  the  NSTS,  including  verification  of  NSTS 
interfaces,  as  required. 

8 . 3 . 2 . 2 Software  Integration 

The  software  integration  process  takes  place  at  many  different  levels 
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throughout  the  system.  Starting  with  the  software  unit  or  module  level,  the 
modules  will  be  successively  integrated  into  increasingly  larger  and 
multi-level  packages. 

To  insure  that  all  contractors/subcontractors  generate  compatible  applications 
software  for  their  subsystem  the  SSE  will  provide  a standard  set  of  tools  and 
resources  for  general  use.  The  Higher  Order  Programming  Languages.  Support 
Software,  Operating  Systems,  and  the  Users  Interface  Language  (UIL),  will  all 
be  standardized . 

8.3.3  Verification 

Verification  is  the  total  process  of  planning  and  implementing  a comprehensive 
program  to  demonstrate  that  the  SSDS  satisfies  all  design,  performance,  and 
safety  requirements . The  verification  process  will  be  an  integration  of 
certification,  development  testing,  acceptance  testing,  integration,  final  on 
orbit  checkout  and  supplemental  analysis  to  support  the  total  verification 
program. 

While  the  final  verification  of  the  System  will  not  be  established  until  the 
IOC  configuration  is  in  place  and  operating  in  the  space  environment,  much  of 
the  verification  effort  will  have  been  accomplished  in  NASA  testbeds  and  other 
development  facilities. 

The  SSE  will  play  a key  role  in  this  verification  effort  in  supporting  and 
furnishing  time  critical,  long  lead  time  items  such  as  operating  systems,  and 
other  software  development  tools  which  are  essential  to  the  timely  and  cost 
effective  usage  of  the  SSE  for  development,  integration/verif ication,  and 
continued  support. 

Based  on  the  SSDS  functional  requirements  defined  in  Task  1,  and  the  System 
Definition  of  Task  4,  all  contractors  will  identify  their  best  estimate  of 
requirements  for  the  SSE  including  language  processors,  simulations, 
diagnostic  routines,  and  sizing  and  loading  requirements . These  requirements 
will  be  refined  and  updated  as  the  SSDS  system  evolves. 
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9.0  TECHNOLOGY  RECOMMENDATIONS 


The  objective  of  this  section  is  to  identify  and  justify  (provide  supporting 
rationale)  those  technology  advancement  items  that  represent  a significant 
"payoff"  to  the  SSDS.  This  assessment  will  consider  both  SSDS  architectural 
needs  as  well  as  ongoing  research  and  technology  development  activities  (NASA, 
DoD,  Industry,  Academia).  The  intent  is  to  provide  the  basis  for  technology 
development  planning  that  will  enhance  cost-effective  capabilities  for  IOC 
and/or  growth  opportunities. 

Technology  items  that  were  potentially  beneficial  to  the  SSDS  were  initially 
identified  and  characterized  during  the  options  development  (Task  2) 
activities.  Since  this  effort  included  the  development  of  projected 
capabilities,  many  advanced  and  immature  technologies  were  considered.  As  the 
system  definition  process  evolved  (supported  by  trade  studies),  preferred 
technologies  were  identified  based  on  their  availability  for  IOC  or  growth. 

In  addition,  an  analysis  was  performed  to  identify  those  technologies  that 
would  have  been  selected  for  IOC  except  for  uncertainties  in  their  maturity 
levels.  As  a result,  they  may  not  have  been  selected  due  to  an  unacceptable 
risk  element.  These  items  were  then  examined  to  determine  the  payoff  for 
continuing,  accelerating  or  initiating  NASA-sponsored  research  and  technology 
development  efforts. 

Table  9-1  lists  the  recommended  technology  advancement  candidates  that  are 
considered  to  have  the  highest  priority.  This  assessment  is  based  on  the 
following  generic  factors. 

a.  Benefit/Cost  Ratio  - Benefits  include  enhanced  performance,  lower 
risk,  improved  crew  productivity/safety  and  customer  accommodation. 
These  are  then  compared  to  estimated  cost  at  IOC  and  growth. 

b.  Leverage  - The  opportunity  to  capture  a substantial  technology  base 
from  other  programs  (i.e.,  VHSIC,  etc.)  with  minimal  investment. 
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Table  9-1 

KEY  TECHNOLOGY  DESIGN/COST  0RIVER5 


TECHNOLOGY 

RATIONALE 

REAL-TIME  EXPERT 
SYSTEMS 

1 0 

INCREASES  CAPABILITIES  OF  EXPERT  SYSTEMS  AND  BROADENS  THE  RANGE  OF  THEIR  SS 
APPLICATIONS.  MAY  REDUCE  SS  OPERATING  COSTS  AND  IMPROVE  PRODUCIIVITY  BY 
RELIEVING  FLIGHT  AND  GROUND  CREW  FROM  ROUTINE  TASKS. 

ADVANCED  SOFTWARE 
DEVELOPMENT /MGT  TOOLS 
& TECHNIQUES 

1 o 

1 ° 

REDUCE  THE  CHANCE  OF  SCHEDULE  SLIPS  AND  COST  OVERRUNS  COMMON  IN  MANY  LARGE 
SOFTWARE  INTENSIVE  PROJECTS. 

IMPROVE  SOFTWARE  DEVELOPMENT  PRODUCTIVITY 

ONBOARD  AI  MACHINES 

s ° 

IMPROVE  SUBSYSTEM  AUTONOMY  AND  PERFORMANCE 

1 ° 

ENHANCE  AUTOMATION  GROWTH  POTENTIAL 

FAULT  TOLERANT  FLIGHT 
COMPUTERS 

I o 

IMPROVE  DATA  SYSTEM  RELIABILITY/AVAILABILITY/MAINTAINABILITY. 

SMART  ADAPTABLE  BUS 
INTERFACE  UNITS 

1 0 

IMPROVES  DATA  SYSTEM  ARCHITECTURE  FLEXIBILITY  AND  WILL  IMPROVE  OVERALL 
NETWORK  PERFORMANCE 

READ/WRITE  OPTICAL  DISK 

i ° 

REDUCE  DATA  ARCHIVAL  COSTS , AFFECTS  DATA  BASE  MANAGEMENT  DESIGN,  MAY  ALLOW 
DATA  CAPTURE  OF  HIGH  DATA  RATE  PAYLOADS  WHEN  OUT  OF  CONTACT  WITH  GROUND 

USER  TEST  AND  CONTROL 
LANGUAGE 

1 ° 
1 0 

REDUCE  PAYLOAD  AND  CORE  SYSTEM  INTEGRATION  AND  CHECKOUT  COSTS 
INCREASE  CREW  PRODUCTIVITY 

1 ° 

GIVE  USERS  MORE  FLEXIBILITY  AND  CAPABILITY  TO  MANAGE  THEIR  PAYLOADS  AND 
SUBSYTEMS 

COLOR  FLAT  PANEL 
DISPLAYS 

i ° 

IMPROVE  CREW  WORKSTATION  "FRIENDLINESS"  AND  EXPAND  CAPABILITIES  WITH  LOWER 
POWER,  WEIGHT,  AND  VOLUME 

DISTRIBUTED  DATA  BASE 
MANAGEMENT  TECHNIQUES 

i ° 

AFFECTS  THE  NUMBER,  AND  PERFORMANCE  REQUIREMENTS  OF  MASS  STORAGE  AND  BUFFER 
MEMORY  DEVICES  AND  THEIR  LOCATION  WITHIN  THE  DATA  NETWORK  ARCHITECTURE  - 
GROUND  AND  SPACE 

i ° 

IMPROVES  USER  ACCESS  TO  STORED  DATA 
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c.  General  Utility  - The  extent  to  which  a technology  can  be  applied 
within  the  SSDS,  the  Space  Station  Program,  or  other  NASA  space 
applications.  In  some  cases  (i.e.,  AI  technology,  etc.),  the  extent 
to  which  the  technology  can  be  applied  beyond  NASA  may  also  be  a 
major  consideration. 

d.  Schedule  - The  urgency  of  starting  an  advancement  effort  to  meet 
desired  use  data.  Includes  benefit  of  accelerating  schedule  to  be 
consistent  with  IOC,  thus  eliminating  costs  associated  with  later 
technology  accommodation.  Also  minimizes  schedule  risk. 

Table  9—1  also  identifies  the  rationale  and  key  benefits  associated  with  each 
recommendation.  Table  9-2  summarizes  the  evaluation  of  each  recommendation  in 
terms  of  the  above  factors . 
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Table  9-2 

TECHNOLOGY  CANDIDATE  EVALUATION 


t 


Benefit/Cost  Ratio 

leveraqe 

General  Utility 

Schedule 

REAL-TIME  EXPERT 

i 

| High 

1 

i ° 

Commercial 

i 

1 Yes 

1 

1 

IOC/Growth 

SYSTEMS 

t 

1 ° 

DOD 

I 

i 

i 

j . 

1 0 
A 

Other  NASA 

1 

I 

[ 

ADVANl.  o software 

1 

i 

1 

| 0 

Primarily  DOD 

1 

1 

1 

1 

DEVELOPMENT/MGT 

| Med ium-to- High 

1° 

Commerc ial 

| Yes 

| 

IOC/Growth 

TOOLS  & TECHNIQUES 

1 

1 

1 

i 

i 

1 

1 

i 

1 0 

Ground  Al  Hardware  | 

| 

IOC  (Maybe) 

ONBOARD  Al  MACHINES 

| High 

I ° 

Other  NASA 

| Yes 

1 

Growth 

_LL 

DOD 

i 

1 

i 

1 ° 

Other  NASA 

1 

| 

FAULT  TOLERANT 

| Med ium-to-High 

1 ° 

DoD 

1 Yes 

| 

IOC 

FLIGHT  COMPUTERS 

i 

_L 

1 0 
1 

Commercial 

i 

i 

1 

1 

1 

1 0 

Other  NASA 

1 

| 

j 

SMART  ADAPTABLE  BUS 

| High 

1 0 

DOD 

| Perhaps 

| 

IOC 

INTERFACE  UNITS 

i 

i _ . 

1 

_L_ 

1 

t 

1 

1 

1 

1 

i 

| 

IOC  (if  feasible) 

READ/WRITE  OPTICAL 

| High 

1 ° 

Commercial 

| Yes 

| 

Growth 

DISK 

i 

A ^ ..  ... 

1 0 
AL. 

DoD 

i 

_i 

1 

j 

1 

1 

| Perhaps  - 

1 

USER  TEST  AND 

| Medium 

1 0 

Other  NASA 

| depending  on  gen- 

| 

IOC 

CONTROL  LANGUAGE 

1 

1 

_1_ 

| erality  of  design 
1 

1 

1 

COLOR  FLAT  PANEL 

1 

l High 

1 

1 ° 

Commercial 

1 

| Yes 

1 

| 

IOC 

DISPLAYS 

i 

J . 

1 0 
1 

DoD 

1 

1 

DISTRIBUTED  DATA 

1 

1 

1 

1 0 

DOD 

i 

i 

I 

| 

BASE  MANAGEMENT 

| High 

1 ° 

Commerc ial 

| Yes 

! 

IOC/Growth 

TECHNIQUES 

i 

J 

1 

_L. 

1 

1 

1 
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10.0 


ISSUES  AND  RECOMMENDATIONS 


As  a preliminary  result  of  the  SSDS  Analysis/Architecture  study  a set  of 
issues  has  been  identified  that  need  to  have  continuing  attention  in  the 
remainder  of  this  study  as  well  as  in  the  Space  Station  Definition  and 
Preliminary  Design  studies  and  related  activities.  These  issues  are  listed 
below  and  (in  some  cases)  contain  recommendations  for  action  that  would  lead 
to  resolution. 

1)  Accuracy  and  completeness  of  the  Mission  Requirements  Data  Base  is 
not  adequate  for  use  as  a firm  basis  for  SSDS  architectural 
decisions,  Correlation  and  elimination  of  redundancy  of  nearly 
identical  proposed  missions  is  still  needed;  complete,  consistent  and 
accurately  timelined  mission  data  is  also  required.  These  conditions 
are  not  expected  to  change  in  the  near-term.  Consequently,  we  have 
accepted  this  data  base  as  a "prototype"  and  have  attempted  to 
speculate  on  reasonable  excursions  for  key  architectural  decisions. 

2)  The  quality,  connectivity,  and  duty  cycle  requirements  for  video  data 
communications  requirements  have  large  excursions  based  on  NASA  and 
contractor  analyses  information. 

3)  The  operational  relationship  between  the  Space  Station  manned  base 
and  the  Co-orbiting  Platform  needs  to  be  clarified  so  that  the 
communications  network  requirements  and  SS  data  management  support 
for  COP  can  be  established.  The  decision  as  to  whether  the  COP  and 
Space  Station  will  be  at  the  same,  or  different,  altitudes , hence 
affecting  line-of-sight  connectivity,  needs  resolution. 

4)  The  impact  of  design-to-cost  (DTC)  goals  has  not  been  factored  into 
the  study  and  relative  cost  data  has  been  used  in  our  design 
analyses.  The  DTC  allocation  could  have  major  impacts  on  level  of 
IOC  automation,  use  of  advanced  technology,  system  flexibility, 
degree  of  system  redundancy,  and  growth  capability.  The  DTC 
allocation  must  be  developed  and  established  as  a key  design  decision 
criteria. 
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5)  The  need  for  security  provisions  has  not  been  fully  explored, 
especially  with  regard  to  potential  DOD  use,  and  the  potential  mixing 
of  commercial,  foreign,  scientific,  and  DOD  users.  Our  study 
considerations  have  been  limited  to  commercial  and  scientific  users. 
Foreign  users  with  technology  transfer  implications  and  DoD  users 
have  not  been  considered. 

6)  Growth  goals  are  only  speculative.  A quantification  of  growth  goals 
is  needed  to  provide  some  consistency  and  discipline  across  the 
various  elements,  systems,  and  technologies  in  the  SS  program.  For 
example,  the  decisions  as  to  whether  NASA  will  implement  TDAS  and 
continue  to  support  ACTS  type  technology  affect  SS  program  growth 
planning.  Realistic  SSDS  growth  goals  need  to  be  established  by  NASA. 

7)  The  tradeoff  between  subsystem  autonomy  and  system  flexibility/ 
expandability  for  onboard  architecture  configurations  has  a wide 
range  of  possible  solutions.  Specific  NASA  feedback  on  our  proposed 
architecture  is  needed  to  guide  future  study  activities. 

8)  The  ability  of  key  technologies  to  support  the  IOC  goals  is  not 
firmly  established  in  certain  areas;  e.g.,  expert  system  planners  and 
schedulers,  space-qualified  AI  hardware,  high  rate  data  capture  and 
routing  technologies,  reliable,  cost-effective  large  volume  data 
storage  technologies.  Realistic  "selection  freeze"  dates  need  to  be 
established  as  a basis  for  IOC  recognizing  the  need  to  minimize  the 
"technology  gap."  Me  expect  that  there  will  be  a range  of  freeze 
date  because  of  different  technical  and  programmatic  factors  for 
different  components. 

9)  The  nature  and  degree  of  foreign  involvement  in  the  program  needs 
better  definition.  This  involvement  has  potential  widespread  effects 
on  the  SSDS  architecture . Will  NASA  be  required  to  capture  and 
distribute  foreign  data?  What  degree  of  monitoring  and  safety 
assurance  will  NASA  have  regarding  foreign  module  operations  cojoined 
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to  the  Space  Station?  Do  foreign  users  need  real-time  interaction 
from  their  home  facilities?  Future  study  activities  should  ensure 
the  accommodation  of  foreign  users  when  their  needs  and  operating 
t modes  are  defined. 


10)  The  degree  of  commitment  by  NASA  to  provide  special  purpose  data 
routing  and  processing  facilities  for  the  few  proposed  very  high  data 
rate  experiments  can  greatly  affect  the  rest  of  the  SSDS  ground 
network  sizing  and  capabilities.  Me  recommend  a specified  range  and 
cost  bogey  for  this  service  be  developed  for  customers  to  evaluate. 
Any  further  analyses  should  be  deferred  pending  customer  community 
assessment . 

11)  The  extent  to  which  the  IS0/0SI  upper  layers  should  be  strictly 
applied  in  the  onboard  LAN,  especially  the  Specific  Application 
Service  Elements  (SASE),  needs  additional  evaluation  before  firm 
design  decisions  are  established. 

12)  The  division  of  the  OSI  layers  between  the  NIU  and  the  SDP  has  not 
been  completely  resolved  and  is  a key  design  decision  requiring 
further  tradeoff  analyses.  Our  current  recommendations  are  included 
in  section  6. 

13)  There  is  still  some  uncertainty  about  the  extent  to  which  hardware 
commonality  should  be  applied  across  SSP  space  elements  due  to 
significant  variations  in  operating  environments.  This  will  be 
further  evaluated  as  COP/POP  requirements  are  developed  and  SS 
architectural  concepts  are  applied  and  evaluated. 
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